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The  Paperwork  Reduction  Act  of  1980  mandated  that  federal 
government  activities  establish  and  enforce  Information 
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establishment  of  a  Data  Administration  Branch  within  federal 
activities  to  provide  an  organizational  entity  devoted  to 
effective  information  management.  This  study  presents 
guidelines  for  the  successful  implementation  of  Data 
Administration,  describes  a  standard  for  an  Information 
Resources  Dictionary  System  (the  Data  Administrator's  primary 
tool) ,  and  makes  recommendations  for  planning  an  Information 
Resources  Dictionary  System  implementation. 
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I .  INTRODUCTION 


A.  BACKGROUND 

The  Naval  Supply  Systems  Command's  (NAVSUP)  mission  is  to 
develop,  manage,  and  operate  the  Navy  Supply  System.  This 
system  exists  to  provide  supplies  and  services  to  satisfy  the 
mission  requirements  of  the  fleet  and  shore  commands  during 
peacetime  and  wartime.  [Ref.  l:p.  6-1] 

Supply  is  a  pervasive  function  that  affects  every  activity 
within  the  Navy  and  many  commercial  contractors  as  well.  This 
global  scope  presents  NAVSUP  with  the  difficult  challenge  of 
controlling,  coordinating  and  exploiting  a  complex  information 
resource  environment. 

Difficulties  arise  because,  until  recently,  NAVSUP  created 
separate  information  systems  and  applications  to  meet  specific 
needs.  This  approach  resulted  in  an  amalgam  of  stand-alone 
systems.  Today  these  aging  systems  exhibit  many  of  the 
classic  problems  which  provide  the  impetus  for  the 
contemporary  Information  Resource  Management  (IRM)  movement: 
data  redundancy,  data  inconsistency,  uncertainty  about  data 
validity,  undisciplined  data  exchanges,  uncontrolled  data 
creation,  unmanaged  system  growth,  and  increasing  program 
maintenance  costs. 

Although  these  problems  still  exist,  NAVSUP  is  now  using 
IRM  techniques  to  modernize  its  information  systems.  For 
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example,  NAVSUP  has  adopted  an  information  engineering 
approach  for  all  new  systems  development.1  In  addition,  a 
Data  Administration  (DA)  organization  presently  exists  which 
is  in  the  process  of  developing  a  Corporate  Data  Dictionary. 
A  Corporate  Data  Dictionary  contains  information  about 
"basically  any  information  entity — a  program,  user,  hardware, 
or  decision  model"  [Ref.  2:p.  48]  that  is  shared  in  an 
organization.  The  Corporate  Data  Dictionary  is  also  referred 
to  as  an  Information  Resource  Dictionary  System  (IRDS) . 

Successful  IRM  implementation  will  provide  the  means  to 
control,  coordinate,  and  exploit  NAVSUP' s  information 
resource.  With  Department  of  Defense  (DOD)  budget  cuts 
imminent,  effective  and  efficient  IRM  is  crucial  to  NAVSUP' s 
ability  to  provide  uninterrupted  service  to  afloat  and  ashore 
customers  in  the  1990's  and  beyond. 

B.  STUDY  OBJECTIVES  AND  SCOPE 

This  study  examines  a  piece  of  the  IRM  infrastructure  at 
NAVSUP  and  its  subordinate  commands,  specifically.  Data 
Administration  and  the  use  of  Information  Resource  Dictionary 
Systems.  The  objectives  are  to  identify  problems  and  issues 


’information  engineering  is  a  structured  methodology  for 
systems  design  and  analysis.  For  a  review  of  information 
engineering  methodology  and  NAVSUP' s  information  engineering 
approach,  see  Sharon  A.  Stanley's  Master's  Thesis,  Naval 
Postgraduate  School,  Monterey,  California,  Information 
Engineering  in  the  Department  of  Defense:  Two  Case  Studies. 
September  1988. 
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hindering  the  successful  implementation  of  this  IRM  subset 
and  to  provide  solutions  and  guidelines  for  their  resolution. 

The  study  encompassed  NAVSUP  Headquarters,  two  Inventory 
Control  Points  (ICP) ,  six  Naval  Supply  Centers  (NSC) ,  and  five 
system  support  offices  responsible  for  functional  area 
support,  e.gv  Navy  Food  Service  Systems  Office  (NAVFSSO) . 

We  chose  these  activities  for  three  reasons.  First,  each 
one  employs  automated  information  systems  to  perform  supply 
functions.  Second,  each  of  these  activities  must  follow 
supply  related  IRM  policies  established  by  NAVSUP.  Lastly, 
together  they  constitute  a  sample  size  large  enough  to  gauge 
accurately  the  extent  and  depth  of  DA  and  IRDS  implementation 
at  NAVSUP  and  its  subordinate  commands. 

C.  RESEARCH  METHODOLOGY 

The  research  methodologies  used  for  collecting  data 
included  a  thorough  review  of  pertinent  literature  to 
ascertain  the  current  practice  of  Data  Administration  and 
Information  Resource  Dictionary  System  implementation. 
Subsequently,  interview  and  survey  techniques  provided  data 
on  NAVSUP' s  progress  and  problems  in  these  areas. 

Interviews  included  in-person  and  telephone  discussions 
with  NAVSUP' s  Data  Administrator,  Fleet  Material  Support 
Office  (FMSO)  Data  Administration  personnel,  and  Information 
Engineering  Systems  Corporation  (IESC)  employees.  IESC  is  a 
commercial  vendor  contracted  to  create  a  Corporate  Data  Model 
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and  a  Corporate  Data  Dictionary  for  NAVSUP.  Additionally,  we 
designed  a  survey  to  capture  Data  Administration  and 
Information  Resource  Dictionary  System  implementation  status 
at  NAVSUP  activities.  The  survey  was  sent  to  the  Data 
Administrators  of  the  commands  listed  in  the  Study  Objectives 
and  Scope  section  above. 

Lastly,  a  comparison  between  accepted  DA  and  IRDS 
standards  and  NAVSUP' s  implementation  status  resulted  in 
proposed  solutions  and  guidelines  for  handling  unresolved 
implementation  issues. 


D.  STRUCTURE/PREVIEW  OF  THE  THESIS 

The  remainder  of  the  thesis  structure  is  as  follows: 

-  Chapter  II  presents  the  findings  of  the  literature  review, 
including  the  current  standards  of  Data  Administration  and 
identification  of  critical  factors  for  its  successful 
implementation . 

-  Chapter  III  describes  the  new  Federal  Information 
Processing  Standard  (FIPS)  for  an  IRDS,  and  identifies 
the  planning  steps  that  need  to  occur  before  implementing 
an  IRDS. 

-  Chapter  IV  includes  a  brief  description  of  NAVSUP' s 
environment,  an  explanation  of  the  methods  used  to  collect 
data  about  NAVSUP 's  DA  and  IRDS  implementation  status,  and 
a  comparison  of  findings  with  the  frameworks  established 
in  Chapters  II  and  III. 

-  Chapter  V  presents  a  summary  of  findings,  recommendations 
for  a  NAVSUP  DA  strategy,  and  areas  for  further  research 
and  study. 

-  Appendix  A  contains  a  list  of  abbreviations. 

-  Appendix  B  contains  the  NAVSUP  Strategic  Information 
System  Architectures  and  Guidelines. 

-  Appendix  C  is  a  copy  of  the  NAVSUP  Data  Administration 
Survey. 
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II.  CRITICAL  FACTORS  FOR  SUCCESSFUL  DATA  ADMINISTRATION 


A.  LITERATURE  REVIEW 

Our  literature  review  yielded  four  major  findings 
pertinent  to  this  study: 

-  a  current  definition  of  Data  Administration  functions; 

-  identification  of  ten  critical  DA  implementation  success 

factors; 

-  a  standard  for  Information  Resource  Dictionary  Systems; 

-  a  framework  for  IRDS  implementation. 

The  literature  review  consisted  of  an  on-line  Dialog 
search2  directed  around  the  following  keywords:  "Information 
Resource  Dictionary  System,"  "Information  Directory  Dictionary 
System,"  "  Data  Dictionary,"  "Data  Dictionary  Implementation," 
"Data  Element,"  "Data  Element  Dictionary,"  and  "Directory 
System."  This  search  produced  a  list  of  hundreds  of  articles 
which  we  subsequently  narrowed  to  about  twenty  with  direct 
applicability  to  our  study. 

The  Knox  Library  at  the  Naval  Postgraduate  School  provided 
the  Dialog  search  and  helped  in  obtaining  articles  from  other 
libraries  in  California.  In  addition,  we  reviewed  several 
theses  at  the  Knox  Library  addressing  Data  Administration  and 
Data  Dictionaries. 


2Dialog  is  an  information  retrieval  service, 
on-line  over  300  databases. 


It  indexes 


Fewer  than  ten  books  on  Data  Administration  and  Data 
Dictionaries  were  identified  by  the  search.  The  relative 
newness  of  DA  as  a  discipline  explains  the  scarcity  of  books. 
Three  of  the  four  main  book  references  used  in  our  study 
appeared  within  the  last  three  years. 

The  reader  should  view  the  DA  critical  success  factors  and 
proposed  strategy  for  IRDS  implementation  presented  in  this 
study  as  guidelines  and  not  hard-and-fast  rules.  Except  for 
the  IRDS,  standards  do  not  exist  for  the  other  findings 
gleaned  from  the  literature  review  process.  It  is  important 
to  remember  that  the  definition  of  DA  is  still  evolving. 
Strategies  developed  today  for  its  successful  implementation 
may  not  be  appropriate  for  the  future. 

E.  AN  INFORMATION  RESOURCE  MANAGEMENT  FRAMEWORK 

IRM  has  evolved  from  the  well-accepted  notion  cf  data  as 
a  primary  resource  in  an  enterprise.  IRM  refers  to  more  than 
just  controlling  data,  however.  It  includes  not  only  all 
forms  of  corporate  data  such  as  voice  data,  image  data,  and 
text  data  [Ref.  2:  p.  176],  but  also  policies,  programs,  and 
manual  records  as  well. 

In  the  public  sector,  Congress  provided  an  impetus  to 
IRM  by  passing  the  Paperwork  Reduction  Act  (PRA)  of  1980  [Ref. 
3:p.  6].  The  PRA  mandated  that  IRM  policies  be  established 
and  enforced  across  the  federal  government.  The  PRA  stressed 
better  management  of  information  technologies  such  as 
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automated  data  processing  and  telecommunications  systems.  It 
specifically  required  the  review  of  information  management 
activities.  The  PRA  also  recommended  the  establishment  of  a 
Data  Administration  Branch  as  part  of  the  Information  Systems 
Management  and  ADP  Security  Division  to  provide  an 
organizational  entity  devoted  to  effective  information 
management . 

The  National  Bureau  of  Standards  (NBS) ,  Special 
publication  500-512  defines  IRM  as  "...  a  set  of  policies  for 
the  coordinated  management  of  an  enterprise's  information 
resources  for  systems  development,  operation,  and 
maintenance."  These  policies  describe  objectives  and 
procedures  to  provide  information  availability,  timeliness, 
accuracy,  integrity,  privacy,  security,  traceability, 
ownership,  use,  and  cost-effectiveness.  In  addition,  they 
provide  the  structure  to  coordinate  information  management, 
processing,  communications,  and  conversion.  [Ref.  4:p.  12] 

IRM  is  a  synchronized  organization-wide  policy  for 
information  control.  This  policy  emphasizes  meeting  the 
myriad  information  requirements  of  diverse  users.  Data 
Administration  is  one  vehicle  that  helps  IRM  fulfill  these 
many  user  requirements. 
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C.  THE  PRACTICE  07  DATA  ADMINISTRATION 

Data  Administration  is  a  corporate  concern  that  recognizes 
data  as  a  resource. 

DA  is  the  establishment  and  enforcement  of  policies  and 
procedures  for  managing  the  company's  data  as  a  corporate 
resource.  It  involves  the  collection,  storage,  and 
dissemination  of  data  as  a  globally  administered  and 
standardized  resource.  [Ref.  5:p.  794] 

The  primary  mission  of  DA  is  effective  information  management 

in  accordance  with  overall  IRM  objectives  [Ref.  4:p.  12].  The 

DA  function  encompasses  all  technical  and  management 

activities  required  for  organizing,  maintaining  and  directing 

a  data  environment  as  shown  in  Table  1. 

Many  of  the  DA  goals  interrelate  in  their  support  of  IRM 
objectives,  for  example,  developing  data  as  a  manageable, 
usable  resource  supports  information  availability.  Without 
manageable  data,  IRM  objectives  can  never  materialize. 
Cataloging  and  inventorying  the  data  resource  supports 
security,  ownership,  and  traceability  objectives,  and  enhances 
data  integrity.  Timeliness  is  an  IRM  objective  which  also 
supports  cost-effectiveness.  Documenting  use  of  the  data 
resource  aids  in  security  and  traceability,  and  helps  ensure 
privacy.  Eliminating  unwanted  repetition  and  improving 
maintenance  of  the  data  resource  supports  the  accuracy, 
integrity,  and  cost-effectiveness  objectives  of  IRM. 
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TABLE  1.  DATA  ADMINISTRATION  GOALS,  TOOLS,  AND  ACTIVITIES 


DATA  ADMINISTRATION  GOALS: 

-Develop  data  as  a  manageable,  usable,  resource 
-Catalog  and  inventory  the  data  resource 
-Provide  timely  availability  of  data 
-Document  use  of  the  data  resource 
-Eliminate  unwanted  redundancy 
-Improve  maintenance  of  the  data  resource 

DATA  ADMINISTRATION  TOOLS: 

-Data  and  business  models 
-Database  management  systems 
-Standards,  procedures  and  naming  conventions 
-Information  Resource  Dictionary  System 

DATA  ADMINISTRATION  ACTIVITIES; 

-Develop  data  models  that  document  types,  resources,  uses 
of  data,  and  relationships  between  data  and  business 
processes 

-Develop  an  IRDS  that  documents  specific  format,  usage, 
and  location  of  data 

-Standardize  data  definitions,  format,  naming  and  coding 
-Develop  documentation  standards  and  information 
security  standards 


Achieving  DA  goals  requires  employing  the  tools  identified 
in  Table  1  as  follows: 

-  Modeling  techniques  allow  the  representation  of  data 
sources,  types,  and  relationships  between  data  and 
business  processes.  A  Conceptual  Model  describes  the  data 
and  the  relationships  found  in  that  data.  It  describes 
data  in  terms  of  objects  such  as  things,  policies,  and 
concepts,  required  to  support  the  business  functions  of 
an  enterprise.  It  would,  for  example,  show  that  an 
accounts  payable  process  relates  to  purchase  orders, 
invoices,  receipt  certification,  and  payment.  A  Logical 
Model  represents  the  required  understanding  of  the  data, 
data  relationships,  and  uses,  as  viewed  by  the  user.  It 
is  a  view  of  the  data  as  used  in  a  particular  user 
environment.  It  can  also  provide  valuable  documentation 
of  the  content  of  a  database.  A  Physical  Model  describes 
the  physical  storage  of  data,  that  is  the  actual  data 
representation  employed  in  the  creation  of  a  database  or 
file. 
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-  A  Data  Base  Management  System  (DBMS)  is  a  software  tool 
that  facilitates  the  management  of  data  and  databases. 
A  schema  is  the  definition  of  the  overall  logical  database 
structure,  i.e.,  the  conceptual  model.  DBMSs  provide 
different  users  with  different  views,  or  subschemas  (or 
logical  models),  of  the  database.  To  manage  the  many 
technical  functions  associated  with  complex  databases,  a 
Data  Base  Administrator  (DBA)  serves  as  a  technical 
assistant  to  the  Data  Administrator.  The  DBA  deals  with 
issues  such  as: 

-  Physical  database  design/ redesign 

-  Database  creation 

-  Database  performance  monitoring  and  evaluation 

-  Technical  procedures 

-  Standards,  procedures,  and  naming  conventions  allow 
standardization  of  data  definitions  underlying  the 
information  resources  of  an  organization.  Standard  naming 
conventions  provide  a  single,  consistent  vocabulary  which 
users  and  programmers  alike  can  understand.  This  allows 
the  MIS  staff,  for  example,  to  examine  and  understand 
which  data  are  being  used  in  procedures,  programs,  and 
files. 

-  The  IRDS  is  a  software  tool  which  provides,  among  other 
things,  data  about  the  data.  The  IRDS  expands  the  concept 
that  a  data  dictionary  serves  as  "an  organized  reference 
to  the  data  content  of  the  organization"  [Ref.  6:p.  51]. 
The  scope  of  the  IRDS  encompasses  a  wider  range  of 
information  resources  than  just  data,  however,  including 
software,  hardware,  users,  and  decision  models. 

The  National  Bureau  of  Standards  has  recently  approved  the 

IRDS  as  an  industry  standard  [Ref.  7].  The  IRDS  is  the 

Federal  Information  Processing  Standard  (FIPS)  for  data 

dictionary  systems  [Ref.  4:p.  1].  A  detailed  discussion  of 

the  IRDS  standard  follows  in  Chapter  III. 

Successful  execution  of  DA  activities  results  from  the 

thorough  integration  and  successful  utilization  of  Data 

Administration  tools.  Each  activity  supports  more  than  one 
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DA  goal.  Collectively  the  activities  provide  an  effective 
basis  for  reaching  established  goals. 

D.  DA  IMPLEMENTATION  8DCCES8  FACTORS 

The  literature  review  identified  ten  factors  applicable 
to  the  successful  implementation  of  a  Data  Administration 
program.  For  simplicity,  these  factors  can  be  grouped  into 
three  broad  categories:  (1)  management  commitment,  (2) 
management  and  organizational  understanding,  and  (3)  an 
appropriate  DA  organization.  A  discussion  of  each  critical 
success  factor  follows  below. 

1.  Full  Management  Commitment 

An  organization  should  not  attempt  to  start  a  Data 
Administration  program  without  first  securing  full  management 
support.  DA  is  an  activity  which  requires  the  cooperation  of 
all  organizational  units.  Only  policies  and  directives  from 
the  highest  levels  of  the  organization  can  provide  this  type 
of  cooperation.  Also,  the  rewards  of  good  data  administration 
usually  do  not  manifest  themselves  until  1-2  years  after 
implementation.  Therefore,  management  commitment  must  be 
patient  and  lasting.  [Ref.  8:p.  55] 

Three  explicit  actions  prove  management  support:  (1) 
Assignment  of  an  adequate  budget  for  DA;  (2)  Proper  placement 
of  the  DA  group  in  the  organizational  structure;  and  (3) 
Public  and  private  DA  program  support. 
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In  a  1981  survey  conducted  by  Gillenson,  20  percent 
of  the  respondents  from  large  system  environments  felt  their 
DA  organizations  had  inadequate  personnel  budgets  [Ref.  9:p. 
705] .  Adequate  budget  support  enables  the  DA  group  to  obtain 
the  resources  required  to  function.  Resources  include 
personnel,  DA  tools  (e.g.,  automated  IRDS) ,  and  office 
supplies. 

In  addition,  DA  group  placement  within  the 
organization  determines  to  a  large  extent  its  effectiveness. 
The  DA  group  should  be  an  individual,  controlling  function, 
separate  from  any  of  the  data  resource  users,  so  that  the 
organization  realizes  impartial  data  resource  management. 
Gillenson  found  that  40  percent  of  the  respondents  with  large 
systems  did  not  place  the  DA  function  high  enough  in  the 
organization.  [Ref.  9:p.  699]  In  another  survey  conducted  in 
1982,  Kahn  reported  64  percent  of  the  responding  organizations 
aligned  DA  functions  directly  under  the  Chief  Information 
Officer  [Ref.  5:p.  797],  Figure  1  depicts  a  suggested 
placement  for  the  DA  function  within  the  corporate 
environment. 

Lastly,  management's  public  and  private  DA  program 
support  is  critical  for  implementing  a  successful  DA  program. 
Public  support  consists  of  communicating  management's  DA 
commitment  through  speeches,  memoranda,  policies,  and 
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Figure  1.  DA  Placement  In  The  Organization 


directives.  Private  support  involves  enforcing  policies 
effectively,  and  includes  the  first  two  factors  of  DA  budgets 
and  organizational  placement. 

2.  Management  and  Organizational  understanding 

Management's  understanding  of  the  DA  concept  and  its 

benefits  are  essential  to  implementation  success.  Kahn  [Ref. 

5]  determined  that  management's  lack  of  understanding  is  an 

inhibitor  of  successful  DA.  Equally  important  is  the  DA 

group's  comprehension  of  management's  strategic  goals. 

In  order  for  the  foundation  to  be  laid  for  the 
establishment  of  data. .. functions,  communication  between 
company  management  and... (DA)  should  be  improved  by 
establishing  a  common  understanding  of  business  strategic 
plans  so... (DA)  and  company  management  can  develop  and 
implement  tactical  system  plans  and  data  plans  [Ref.  8:p. 
56] . 
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Relating  the  benefits  of  DA  directly  to  the  corporate 
strategic  goals  can  foster  a  common  understanding  of  DA. 
Simply  stating  the  traditional  benefits  of  DA,  such  as  more 
data  sharing,  more  consistent  information,  increased  knowledge 
of  the  data  available,  better  systems  planning,  and  reduced 
costs,  will  not  suffice  to  convince  top  management  that  the 
DA  concept  is  worthy  of  their  attention.  Data  plans  and 
systems  development  efforts  must  be  integrated  with  business 
requirements . 

The  business  benefits  sought  by  a  DA  policy  provide  an 
important  contextual  framework  for  associating  missions 
and  goals  of  the  organization  with  those  of  the  policy 
[Ref.  10:p.  2-4]. 

Organizational  understanding  is  harder  to  achieve. 
The  first  step  is  to  define  clearly  DA  responsibilities  and 
scope.  Creating  policies  and  directives,  then  ensuring  their 
thorough  dissemination,  can  accomplish  this.  It  helps  to 
include  an  information  architecture  in  the  DA  policy.  The 
information  architecture  introduces  a  small,  but  substantial 
element  of  "how,"  which  provides  a  common  vision  for  all  data 
users.  [Ref.  10:p.  4-5] 

Harder  still  is  convincing  people  that  data,  which 
they  once  strictly  owned,  is  now  shared  data.  For  example, 
the  Sales  Manager  may  no  longer  exclusively  control  the  data 
in  the  sales  database.  Other  departments  like  Inventory 
Control  can  access  it  for  their  own  purposes.  In  addition, 
the  implementation  of  a  DA  program  will  cause  changes  in  the 
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job  responsibilities  of  some  people.  People  resist  these 
changes.  [Ref.  9:p.  705] 

A  thorough  DA  education  and  training  program  can 
overcome  these  organizational  resistance  factors.  Support 
from  management,  a  clear  definition  of  DA  responsibilities 
and  scope,  and  the  authority  to  enforce  DA  policies  form  a 
solid  foundation  on  which  to  build  a  DA  education  and  training 
program . 

3.  Appropriate  DA  Organization 

Support  from  top  leaders  and  organizational 
understanding  of  the  DA  concept  are  but  two  legs  of  the 
triangle  of  elements  needed  to  introduce  a  successful  DA 
program.  The  third  leg  is  the  actual  staff  responsible  for 
DA.  Kahn  [Ref.  5]  found  that  an  insufficient  DA  staff  was 
another  inhibitor  of  successful  DA  implementation. 

Two  components  characterize  an  insufficient  DA  staff: 
an  inadequate  number  of  employees;  and/or  employees  without 
adequate  knowledge  about  or  experience  in  DA.  Kahn  [Ref.  5] 
found  that  most  organizations  assigned  four  employees  to  the 
DA  function.  Gillenson  [Ref.  9]  reported  large  system 
organizations  that  considered  themselves  successful  had  at 
least  6-7  employees  in  the  DA  function. 

A  more  subtle  problem  is  finding  experienced  DA 
personnel.  The  scarcity  of  resources  caused  by  the  relative 
newness  of  the  DA  discipline  significantly  hinders  the 
recruitment  effort. 
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Lastly,  both  Gillenson  [Ref.  9]  and  Kahn  [Ref.  5] 
described  DA  staff  workload  as  a  success  factor  when 
implementing  DA.  The  key  here  is  to  start  small.  The  DA 
should  apply  DA  techniques  to  a  single  application  or  system. 
For  example,  DA  techniques  could  be  applied  initially  to  an 
inventory  control  application  rather  than  all  program 
applications.  In  the  process,  DA  staff  can  prove  DA 
techniques  work,  gain  staff  experience,  and  build 
organizational  confidence  in  DA. 

Table  2  summarizes  the  critical  factors  for  successful 
DA  implementation.  In  Chapter  IV  we  use  these  success  factors 
to  analyze  NAVSUP's  DA  program. 

A  necessary  tool  for  successful  DA  implementation  is 
the  IRDS.  The  next  chapter  discusses  the  Federal  Information 
Processing  Standard  for  an  Information  Resource  Dictionary 
System.  Modules  that  comprise  the  IRDS  are  discussed,  and 
implementation  planning  steps  are  identified. 
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TABLE  2.  CRITICAL  SUCCESS  FACTORS  FOR  DA  IMPLEMENTATION 


I.  FULL  MANAGEMENT  COMMITMENT 

a.  Sufficient  Budget  for  Necessary  Resources 

b.  Proper  DA  Placement  in  the  Organization 

c.  Public  and  Private  DA  Program  Support 

II.  MANAGEMENT  &  ORGANIZATIONAL  UNDERSTANDING 

a.  Relate  DA  Concept  to  Business  Goals 

b.  Clearly  Define  DA  Responsibilities  &  Scope 

c.  Give  DA  Authority  to  Enforce  DA  Policies 

d.  Provide  Organizational  DA  Education  &  Training 

III.  APPROPRIATE  DA  ORGANIZATION 

a.  Adequately  Staff  DA  Organization 

b.  Knowledgeable  and  Experienced  DA  Staff 

c.  Realistic  Workload  (Goals)  for  DA  Staff 
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III.  INFORMATION  RESOURCE  DICTIONARY  8YSTEM  STANDARD  AND 

IMPLEMENTATION  PLANNING 

A.  INFORMATION  RESOURCE  DICTIONARY  8YSTEM  (IRDS)3 
l.  Benefits  of  an  IRDS 

A  cost-benefit  overview  was  prepared  in  1983  for  the 
Institute  for  Computer  Sciences  and  Technology,  National 
Bureau  of  Standards.  It  estimated  that  the  federal  government 
could  realize  over  $120  million  (in  constant  1983  dollars)  in 
benefits  by  the  early  1990s  through  use  of  a  standard  IRDS. 
Cost  reduction  and  avoidance  opportunities  identified 
included: 

-  Improved  identification  of  existing  information  resources 
made  available  to  others  in  the  same  organization  or 
shared  with  other  organizations. 

-  Reductions  of  unnecessary  development  of  computer  programs 
when  suitable  programs  already  exist. 

-  Simplified  software  and  data  conversion  through  use  of 
consistent  documentation. 

-  Increased  portability  of  acquired  skills  resulting  in 
reduced  personnel  training  costs. 

In  addition  to  the  cost  benefits  identified,  the 
standard  directly  supports  Data  Administration  goals  through 
the  following: 


3Except  as  noted,  the  source  of  information  for  this  IRDS 
section  is  "A  Technical  Overview  of  the  Information  Resource 
Dictionary  System  (Second  Edition),”  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards  Publication  NBSIR  88-3700,  January 
1988. 
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-  Aid  development,  modification,  and  maintenance  of  manual 
and  automated  systems  throughout  their  life-cycle. 

-  Support  a  data  element  standardization  program. 

-  Support  records,  reports  and  forms  management,  for  non- 
automated  through  fully  automated  environments. 

2.  IRDS  Design  Objectives 

Recognizing  that  dictionary  system  technology  is 
evolving  and  that  use  of  dictionary  systems  is  expanding, 
three  major  objectives  were  identified:  [Ref.  11 :p.  50] 

-  The  IRDS  should  contain  the  major  capabilities  of  existing 
dictionary  systems. 

-  The  IRDS  should  be  modularized  to  support  a  wide  range  of 
user  environments  and  to  support  cost-effective 
procurement . 

-  The  IRDS  should  support  portability  of  skills  and  data. 

To  satisfy  the  first  objective,  both  federal 
government  representatives  and  dictionary  software  vendors 
reviewed  draft  versions  of  the  IRDS  Specifications.  Reviews 
focused  on:  (1)  functions  required  by  users  of  their 
dictionary  systems;  and  (2)  the  feasibility  of  carrying  out 
the  specified  IRDS  functions.  As  a  result  of  these  reviews, 
the  IRDS  specifications  include  the  most  commonly  used 
facilities.  It  represent  a  "state-of-the-practice"  level  of 
technology. 

Designed  in  modular  style,  the  standard  provides 
flexibility  and  procurement  cost-effectiveness.  The  Standard 
includes  a  "Core"  dictionary  system  Module  plus  specifications 
for  six  additional  Modules.  All  IRDS  Modules  interface  with 
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the  Core  Module,  although  they  are  independent  of  one  another. 
Organizations  have  the  flexibility  to  acquire  one  or  more  of 
the  five  additional  Modules  to  satisfy  their  requirements. 
The  Core  Module  contains  a  basic  set  of  capabilities  described 
in  the  paragraphs  below. 

To  provide  portability  of  skills,  the  Core  IRDS  Module 
contains  two  user  interfaces.  They  are  a  menu  driven  "Panel" 
Interface  and  a  Command  Language  Interface.  The  Panel 
Interface  supports  interactive  processing.  It  leads  users 
down  a  structured  path  of  screens  (i.e.,  panels),  and 
accommodates  inexperienced  users.  Thus,  technical  and  non¬ 
technical  staff  can  execute  IRDS  functions  with  no 
understanding  of  the  syntax  of  the  Command  Language  Interface. 
The  Command  Language  Interface  operates  in  batch  or 
interactive  mode. 

In  support  of  portability  of  data  an  IRD-to-IRD 
interface  exists.  An  Information  Resource  Dictionary  (IRD) 
is  one  application  of  the  IRDS.  The  IRD-to-IRD  interface 
facility  provides  a  controlled  method  of  moving  data  from  one 
standard  Information  Resource  Dictionary  to  another. 
Organizations  using  a  standard  IRDS  could,  for  example, 
extract  data  from  a  decentralized  IRD  and  add  it  to  a  central 
IRD  that  focuses  on  corporate-wide  data. 

3.  User's  View 

The  IRDS  Standard  consists  of  entities,  relationships, 
and  attributes.  An  entity  name  corresponds  to  nouns.  Entities 
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represent  or  describe  a  real-world  concept,  person,  event,  or 
quantity,  but  it  is  not  the  actual  data.  For  example,  an 
entity  might  be  Social-Security-Number.  An  instance  of  the 
actual  social  security  number  is  555-55-5555.  Note  that 
Social -Security-Number  is  an  entity  in  the  IRDS  since  it 
describes  a  data  item;  however,  in  the  operational  database 
context,  Social-Security-Number  is  an  attribute  which 
describes  some  other  entity  like  Employee.  This  illustrates 
the  basic  difference  between  the  contents  of  the  IRDS  and  the 
operational  databases  which  it  describes.  A  relationship  name 
corresponds  to  verbs.  Relationships  show  an  association 
between  two  IRD  entities.  For  example,  a  Payroll -Record 
"CONTAINS"  Social-Security-Number.  An  attribute  name 
corresponds  to  adjectives  or  adverbs.  Attributes  describe 
characteristics  of  an  entity  or  relationship.  One  attribute 
of  Social-Security-Number  is  LENGTH,  with  a  value  of  nine  in 
this  example. 

Although  the  IRDS  Standard  uses  entities, 
relationships,  and  attributes,  it  supports  alternate 
approaches  to  implementation.  Any  data  base  management 
system,  using  standard  DBMS  capabilities,  can  design  a 
software  system  to  implement  the  Standard.  [Ref.  11 :p.  55] 

An  important  aspect  of  the  IRDS  is  that  it  is  strongly 
typed.  Each  entity,  attribute,  or  relationship  has  an  entity- 
type,  attribute-type,  or  relationship-type,  respectively  [Ref. 
ll:p.  50].  Entity-type  is  a  label  for  a  set  of  entities  which 


21 


have  a  similar  concept  and  share  a  set  of  common  attribute- 
types.  For  example,  in  Figure  2  entity-type  ELEMENT  has  as 
instances  the  entities  Social -Security-Number  and  Employee- 
ID.  The  ELEMENT  entity-type  has  attribute- type  LENGTH. 

Relationship-type  is  a  label  for  a  set  of 
relationships  which  have  similar  meanings  and  share  a  set  of 
common  attribute-types.  In  the  Relationship-Type  RECORD- 
CONTAINS -ELEMENT  shown  in  Figure  2 ,  the  entity-types  RECORD 
and  ELEMENT  have  common  attribute-types  LENGTH  and  ALLOWABLE- 
RANGE. 

Attribute-type  is  a  label  for  a  set  of  attributes 
which  may  be  common  to  an  entity-type  or  relationship-type. 
Figure  2  shows  that  LENGTH  is  an  attribute-type  for  the 
entity-type  RECORD,  and  ALLOWABLE-RANGE  is  an  attribute-group- 
type  for  the  entity-type  ELEMENT. 

An  attribute-group-type  is  an  ordered  set  of  two  or 
more  attribute-types  used  together.  In  the  example  above, 
ALLOWABLE -RANGE  might  consist  of  the  attribute-types  LOW-OF- 
RANGE  and  HIGH-OF-RANGE .  The  value  for  LOW-OF-RANGE  by  itself 
does  not  convey  clear  meaning,  so  it  is  grouped  with  a  HIGH- 
OF-RANGE  value. 

4.  Core  Module — Module  l 

The  Core  Module  provides  basic  capabilities  as 
discussed  below: 
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IRD  Vv  M8ta-£ntny,  j  Relationship-  j  Attribute-Type 


Figure  2.  IRDS  Content 


a.  Schema 


IRD  Schema  describes  the  structure  of  the  IRD. 
For  every  entity,  relationship,  attribute,  and  attribute-group 
that  exists  in  the  IRD,  the  IRD  Schema  contains  a 
corresponding  entity-type,  relationship-type,  attribute-type 
and  attribute-group-type.  Metadata  describes  the  structural 
characteristics  of  the  data  [Ref.  4:p.  50].  Therefore,  the 
IRD  Schema  contains  meta-entities,  meta-relationships,  meta¬ 
attributes,  and  meta-attribute-groups,  shown  in  Figure  2. 

The  IRDS  provides  many  predefined  schema 
structures.  Every  implementation  of  the  IRDS  includes  the 
Minimal  Schema  as  part  of  the  IRDS  Core  Module.  It  contains 
a  set  of  schema  descriptors  necessary  to  establish  control 
over  the  IRD.  A  sample  Minimal  Schema  is  shown  in  Table  3. 
The  upper  portion  of  Table  3  identifies  types  that  will 
control  and  regulate  access  to  the  contents  of  the  IRD  and  IRD 
Schema.  The  lower  portion  identifies  types  that  will  document 
changes  to  the  IRD  and  the  IRD  Schema.4 


4The  complete  Minimal  Schema  is  listed  in  Appendix  A  of  "A 
Technical  Overview  of  Information  Resource  Dictionary  Stystem 
(Second  Edition), ”  U.  S.  Department  of  Commerce,  National  Bureau 
of  Standards  Publication  NBSIR  88-3700,  January  1988. 
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TABLE  3.  MINIMAL  SCHEMA  EXAMPLE 


To  control  and  regulate  access  to  the  contents  of  the  IRD 
and  the  IRD  Schema: 

Entitv-Tvpe: 

IRDS-USLR 
IRD- VIEW 
IRD-SCHEMA-VIEW 

Relationship-Types : 

IRDS-USER-HAS-IRD-VIEW 

IRDS -USER-HAS -IRD-SCHEMA-VIEW 

Attribute-Tvpe : 

DEFAULT-VIEW 


To  automatically  document  audit  information  concerning 
changes  to  the  IRD  and  the  IRD  Schema: 

Attribute-Types : 

ADDED-BY 
LAST-MODI FIED-BY 
NUMBER-OF-TIMES -MODIFIED 

Attribute-Group-Types : 

DATE-TIME-ADDED 
DATE-TIME -MODIFIED 
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b.  Life-Cycle-Phases 


The  Core  Module  includes  a  life  cycle  phase 
facility.  This  allows  an  organization  to  define  life-cycle- 
phases  that  correspond  to  the  methodology  used  by  the 
organization.  A  user  documents  the  life-cycle-phase  in  which 
the  entity  exists,  that  is,  assigns  each  entity  to  a  life¬ 
cycle-phase.  Different  entities  can  be  associated  with,  for 
example,  the  Requirements  Definition  Phase,  or  the  Logical 
Database  Design  Phase. 

The  Core  Module  also  includes  a  life-cycle-  phase 
partition  facility.  It  provides  the  user  with  the  capability 
to  construct  partitions  in  the  IRD  that  correspond  to  the 
life-cycle-phases.  Every  user  operates  in  an  IRD-view,  and 
each  IRD-view  relates  to  a  partition.  Each  IRD-partition 
belongs  to  one  of  the  following  three  life-cycle-phase 
classes: 

-  Uncontrolled — represents  non-operational  stages  of  a 
system  life  cycle,  such  as  specification,  design,  or 
development. 

-  Controlled — designed  for  entities  that  describe  data 
existing  in  operational  systems. 

-  Archived — documents  entities  no  longer  in  use. 

Module  4  addresses  control  of  life-cycle 
management  in  greater  depth, 
c.  Versioning 

A  flexible  and  generalized  facility  enables  users 
to  assign  different  types  of  names  to  an  entity.  Different 
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names  serve  distinct  purposes.  Understanding  the  use  of  and 
distinction  between  access-name,  descriptive-name,  and 
alternate-name,  is  basic  to  understanding  the  IRDS. 


An  access-name  is  the  entity's  primary  identifier. 
It  has  two  parts:  an  assigned  access-name  and  a  version- 
identifier.  Normally  a  user  will  specify  the  assigned  access- 
name.  An  option  exists  to  have  the  IRDS  generate  the  assigned 
access-name  for  entities  of  a  given  type.  A  version- 
identifier  consists  of  two  parts — a  variation-name  and  a 
revision-number.  A  variation-name  is  optional,  that  is,  only 
those  entities  that  have  been  explicitly  assigned  variation- 
names  have  them.  All  entities  have  revision-numbers. 
Revision-number  "1”  represents  the  initial  entity  before  the 
first  revision.  For  example,  the  third  revision  of  the 
statistical  module  with  five  digit  precision  is  Stat-Module- 
(Precision-5:3) .  The  statistical  module  with  eight  place 
precision  and  no  revisions  is  Stat-Module (Precision-8 : 1) . 

A  descriptive-name  helps  non-technical  users  and 
managers  unfamiliar  with  the  contents  of  the  IRDS.  Users 
assign  a  descriptive-name,  normally  longer  and  more  meaningful 
than  the  access-name.  The  structure  of  the  descriptive-name 
is  the  same  as  that  of  the  access-name.  It  includes  an 
assigned  descriptive-name  and  a  version-identifier. 

Access-names  and  descriptive-names  must  be  unique 
throughout  an  IRD.  The  user  cannot,  for  example,  have  a  FILE 
entity  with  an  access-name  Payroll  and  a  RECORD  entity  with 
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an  access-name  Payroll.  For  those  individuals  thoroughly 
familiar  with  the  IRDS,  this  might  seem  overly  restrictive. 
That  is,  it  might  seem  quite  reasonable  to  have  a  Payroll 
SYSTEM  which  accesses  the  Payroll  FILE  which  consists  of 
Payroll  RECORDS.  We  believe  that  for  those  users  less 
familiar  with  the  IRDS,  duplication  of  access-names  would 
cause  confusion  and  unnecessary  complication.  Besides 
eliminating  potential  problems,  this  feature  simplifies 
Command  Language  and  Panel  Interfaces.  Except  during  actual 
entity  creation,  the  IRDS  recognizes  the  entity-type  for  every 
entity  name  included  in  a  command  or  panel, 
d.  Views 

The  Core  provides  both  IRD-views  and  IRD-schema- 
views.  A  view  defines  an  environment  in  which  a  user  works 
with  an  IRD.  An  IRD-view  includes: 

-  A  set  of  entities  of  specified  types,  with  their 
attributes  and  attribute-groups.  All  entities  in  the  IRD- 
view  are  in  the  same  partition. 

-  A  set  of  relationships  of  specified  types,  with  their 
attributes  and  attribute-groups,  that  exist  between  the 
entities. 

An  IRD-schema-view  includes: 

-  A  set  of  meta-entities,  with  their  meta-attributes  and 
meta-attribute-groups . 

-  A  set  of  meta-relationships,  with  associated  meta¬ 
attributes  and  meta-attribute-groups,  that  exist  between 
meta-entities. 
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5.  Basic  Functional  Schema — Module  2 

Module  2  of  the  Specifications,  supports  intra-  and 
inter-organization  communications  about  information  resources. 
It  defines  a  "starter  set"  of  entity-types,  relationship- 
types,  and  attribute-types.  The  Basic  Functional  Schema  will 
satisfy  most  existing  and  planned  manual  and  automated 
systems.  An  organization  can  augment  the  Basic  Functional 
Schema  using  the  IRDS  extensibility  feature. 

The  Basic  Functional  Schema  contains  the  eight  entity- 
types  shown  in  Table  4.  The  relationship-types  include  most 
of  the  connections  between  Basic  Functional  entity-types  that 
might  prove  useful  to  an  organization.  Seven  predefined 
relationship-class-types  exist  for  the  user.  Table  5  lists 
these.  Entity  types  can  be  the  first  and  second  member  of  a 
relationship-type,  such  as  PROGRAM-CONTAINS -MODULE.  The 
relationship-type  can  also  be  recursive,  for  example  MODULE - 
CONTAINS -MODULE . 

The  Basic  Functional  Attribute-Types  are  shown  in 
Table  6.  They  apply  to  the  entity-types  identified  in  Table 
4.  For  example,  attribute-types  Classification  and 
Description  apply  to  all  entity-types.  Ordered  sets  of 
attributes  are  called  attribute-groups.  They  are  also 
included.  For  example,  the  attribute-group-type  ALLOWABLE- 
RANGE  consists  of  attribute-types  LOW-IN-RANGE  and  HIGH-IN- 
RANGE.  Attribute-group-type  ALLOWABLE-RANGE  relates  to  the 
single  entity-type  ELEMENT  identified  in  Table  4. 
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TABLE  4 


BASIC  FUNCTIONAL  ENTITY-TYPE 


1.  DOCUMENT:  describes  instances  of  human  readable  data 
collections,  for  example,  1988-Annual-Report. 

2.  ELEMENT:  describes  instances  of  data  belonging  to  the 
organization,  for  example,  Employee-Id. 

3.  FILE:  describes  instances  of  data  collections,  for 
example,  Payroll-File. 

4.  MODULE:  describes  instances  of  automated  processes 
that  are  logical  subdivisions  of  PROGRAM  entities  or 
independent  processes  that  are  called  by  PROGRAM 
entities,  for  example,  Sort -Records  and  Check- 
Spelling. 

5.  PROGRAM:  describes  instances  of  automated  processes, 
for  example,  Print-Paychecks. 

6.  RECORD:  describes  instances  of  logically  associated 
data,  for  example.  Payroll -Record. 

7.  SYSTEM:  describes  instances  of  collections  of 
processes  and  data,  for  example,  Payroll-System. 

8.  USER:  describes  individual  or  organizational 
component,  for  example,  Comptroller-Department  and 
Jane-Doe. 
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TABLE  5.  BASIC  FUNCTIONAL  RELATIONSHIP-TYPE 


1.  CALLS :  describes  reference  associations  between 
PROCESS  entities.  For  example,  a  CALLS  Relationship- 
type  is  PROGRAM-CALLS -MODULE,  which  has  as  a  possible 
instance  Main-Program-CALLS-Sort -Routine . 

2.  CONTAINS:  describes  instances  of  an  entity  being 
composed  of  other  entities.  For  example,  a  CONTAINS 
Relationship-type  is  RECORD-CONTAINS -ELEMENT,  which 
has  as  a  possible  instance  the  relationship  Payroll- 
Record-CONTAINS -Employee  Name. 

3.  DERIVED-FROM:  describes  associations  between  entities 
involving  a  calculation.  For  example,  a  DERIVED-FROM 
Relationship-type  is  DOCUMENT-DERIVED-FROM-FILE,  which 
has  as  a  possible  instance  Annual-Report-DERIVED-FROM- 
Program-File. 

4.  GOES-TO:  describes  flow  associations  between  PROCESS 
entities.  For  example,  a  GOES-TO  Relationship-type  is 
PROGRAM-GOES-TO-PROGRAM  which  has  a  possible  instance 
the  relationship  Input-Program-GOES-TO-Processing- 
Program. 

5.  PROCESSES:  describes  associations  between  PROCESS  and 
DATA  entities.  For  example,  a  PROCESSES  Relationship- 
type  is  SYSTEM-PROCESSES-FILE,  which  has  as  a  possible 
instance  the  relationship  Budget-System-PROCESSES- 
Cost-Center-File . 

6.  RESPONSIBLE-FOR:  describes  associations  between 
organizational  component  entities  and  other  entities, 
denoting  organizational  responsibility.  For  example, 
a  RESPONSIBLE-FOR  Relationship-type  is  USER- 
RESPONSIBLE-FOR-Payrol 1-System. 

7.  RUNS:  describes  associations  between  USER  and  PROCESS 
entities.  For  example,  a  RUNS  Relationship-type  is 
USER-RUNS -PROGRAM,  which  has  as  a  possible  instance 
the  relationship  Jane-Doe-RUNS-System-Backup. 
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TABLE  6.  BASIC  FUNCTIONAL  ATTRIBUTE-TYPES 
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6.  IRD8  Security — Module  3 


This  module  defines  an  access  control  facility.  It 
allows  organizations  to  restrict  access  to  the  IRD  and  IRD 
Schema  content  and  functionality.  This  facility  provides  two 
levels  of  access  control: 

a.  Global  Security 

Functionality,  type,  and  view  combine  to  define 
global  security.  For  each  IRDS  user,  one  IRDS-USER  entity 
exists.  Attributes  associated  with  this  entity  define 
thelevel  of  access,  for  example,  permission  to  use  the  Command 
Language  Interface.  Associated  with  each  IRD-VIEW  and  IRD- 
SCHEMA-VIEW  entity  are  attributes  and  attribute-groups.  They 
define  access  for  all  IRDS  users  allowed  to  use  the  views. 
This  includes  read,  add,  modify  and  delete  permission  for  each 
entity-type  and  meta-entity-type.  Each  IRDS-USER  entity  links 
to  those  IRD-VIEW  and  IRD-SCHEMA-VIEW  entities  through  IRDS- 
USER-HAS -IRD-VIEW  and  IRDS-USER-HAS-IRD-SCHEMA-VIEW 
relationships . 

b.  Entity- Level  Security 

This  facility  allows  assignment  read  and  write 
privileges  for  individual  entities.  Entity-Level  Security 
allows  ten  digit  number  read  or  write  locks,  assigned  by  the 
system,  to  each  entity  requiring  security.  Users  attempting 
to  access  a  secured  entity  must  have  the  correct  ten  digit 
number  key.  Only  those  users  granted  permission  to  access 
an  entity  secured  in  this  fashion  have  keys  issued  to  them. 
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7.  Extensible  Life-Cycle-Phase  Facility — Module  4 


This  Module  extends  the  life-cycle-phase  facilities 
of  the  Core  Module.  It  implements  integrity  rules  and 
controls  the  movement  of  entities  through  the  life  cycle.  As 
in  the  core,  this  module  provides  life-cycle-phase  designation 
for  non-operational,  operational,  and  archived  entities.  Three 
additional  capabilities  include  Hierarchical  Phase  Modeling, 
Relationship  Sensitivity  Structures,  and  Life  Cycle  Integrity 
Rules  [Ref.  4:p.  33], 

a.  Hierarchical  Phase  Modeling 

This  allows  users  to  designate  hierarchical 
relationship  among  phases.  For  example,  during  development, 
the  Requirements  Phase,  which  might  include  specification  and 
design  phases,  is  designated  as  the  top  of  the  hierarchy.  When 
the  system  is  operational,  the  hierarchal  model  is  revised, 
with  the  Controlled  Phase  at  the  top,  and  the  Requirements 
Phase  beneath. 

b.  Relationship  Sensitivity  Structure 

This  allows  users  to  classify  relationships  as 
phase-related.  In  a  phase-related  relationship,  one  entity 
"depends  on"  another  entity.  For  example,  assume  the 
relationship-type  PROGRAM-ACCESSES -SUBROUTINE  is  phase- 
related.  The  first  entity  in  the  relationship  is  dependent 
on  the  second  entity,  while  the  second  entity  is  independent 
of  the  first.  The  entities  of  type  PROGRAM  are  dependent  on 
entities  of  the  type  SUBROUTINE.  To  be  complete,  entities  of 
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type  PROGRAM  require  the  presence  of  entities  of  type 
SUBROUTINE. 

The  phase-related  dependency  extends  to  the 
specific  relationships  of  the  relationship-type.  For  example, 
in  the  relationship-type  PROGRAM-ACCESSES-SUBROUTINE,  the 
entity  PRODUCE -PAYROLL  (entity-type  PROGRAM)  has  a  phase- 
related  dependency  on  entity  PREPARE-CHECKS  (entity-type 
SUBROUTINE) .  Phase-related  relationship  dependencies  provide 
a  foundation  for  the  IRDS  to  enforce  life  cycle  integrity 
rules. 

c.  Life  Cycle  Integrity  Rules 

Life-cycle  integrity  rules  protect  the  IRD  when 
moving  an  entity  from  an  Uncontrolled  life-cycle-phase  to  a 
Controlled  life-cycle-phase,  or  from  a  Controlled  life-cycle- 
phase  to  an  Archived  life-cycle-phase.  Using  the  Relationship 
Sensitivity  Structure  above,  independent  entities  must  exist 
in  the  Controlled  or  Archived  life-cycle-phase  before  moving 
dependent  entities  to  those  phases.  Using  the  PROGRAM- 
ACCESSES-SUBROUTINE  example  from  above,  when  the  user  moves 
PRODUCE-PAYROLL  and  PREPARE-CHECKS  from  an  Uncontrolled  life¬ 
cycle-phase  to  the  Controlled  phase,  the  independent  entity 
PREPARE-CHECKS  must  be  in  the  Controlled  phase  before  the 
dependent  entity  PRODUCE-PAYROLL  moves  there. 

8.  Procedure  Facility— Module  5 

This  Module  provides  the  user  with  the  ability  to 
define  and  execute  new  IRDS  procedures,  or  macros,  for  IRDS 


commands.  This  allows  storage  of  lengthy  commands,  can 
simplify  entry  of  repetitive  commands,  and  allows  use  of 
Assignment  Statements,  DO  statements,  and  IF  statements. 

9.  Application  Program  interface — Module  6 

The  Application  Program  Interface  provides  an 
interface  between  standard  programming  languages  and  the 
command  language  of  the  IRDS.  Users  can  write  programs  to 
collect  data  from,  and  pass  data  to,  the  IRD.  The  Call 
feature  of  the  programming  language  accomplishes  the 
interface.  This  interface  enforces  all  IRDS  integrity  and 
security  rules. 

10.  IRDS  Services  Interface— Module  7 

This  Module  defines  a  specific  protocol  for  an 
interface  that  will  allow  software  external  to  an  IRDS  direct 
access  to  the  IRD  and  IRD  Schema.  The  Services  Interface  uses 
data  structures  that  are  more  basic  than  those  used  by  the 
Command  Language  or  Panel  Interfaces.  It  is  more  flexible  and 
potentially  more  efficient  than  the  Application  Program 
Interface.  Examples  of  external  software  that  could  use  the 
provided  services  are: 

-  Programming  language  compilers 

-  Database  query  languages  like  Structured  Query  Language 

(SQL)  and  Network  Data  Language  (NDL) 

-  Information  locator/retrieval  systems 

-  Report  writers 

-  Text  editors 
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Providing  external  software  direct  access  to  the  IRD 
and  IRD  Schema  is  significant.  It  creates  an  environment  that 
allows  the  IRDS  to  be  active  in  an  operating  environment. 

In  summary,  an  Information  Resource  Dictionary  System 
is  a  software  system  that  conforms  to  Federal  Information 
Processing  Standards  for  data  dictionary  systems.  It  provides 
the  user  a  useful,  flexible,  and  extensible  system  that  will 
support  all  phases  of  a  system  life  cycle.  The  modular 
structure  provides  a  common  set  of  features  in  the  Core  module 
and  in  optional  modules. 

Features  in  the  Core  Module  include  the  minimal  Schema 
necessary  to  establish  control  over  the  IRD.  The  life-cycle- 
phase  facility  allows  organizations  to  define  life-cycle- 
phases  that  correspond  with  their  life-cycle  methodology. 
Versioning  enables  users  to  assign  different  types  of  names 
to  an  entity.  Views  define  the  environment  in  which  a  user 
works . 

The  Basic  Functional  Schema  Module  supports  intra-and 
inter-organization  communications  and  defines  a  starter  set 
of  entity-types,  relationship-types,  and  attribute-types.  A 
Security  Module  provides  restricted  access,  and  controls,  to 
the  IRD  and  IRD  Schema.  The  Extensibility  Module  implements 
integrity  rules  and  controls  entity  movement  throughout  a 
life-cycle.  The  Procedure  Module  allows  user-defined  macros, 
and  allows  use  of  DO,  IF,  and  Assignment  Statements.  The 
Interface  Module  provides  an  interface  between  standard 
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programming  languages  and  the  IRDS  Command  Language .  The 
Services  Module  defines  a  protocol  for  an  interface  that  will 
allow  direct  IRD  and  IRD  Schema  access  to  software  external 
to  the  IRDS. 

Implementing  the  IRDS  standard  will  benefit  any 
organization.  Organizations  with  multiple  IRDS  products  from 
different  vendors  will  increase  user  efficiency,  and 
transportability  through  the  common  set  of  IRDS  features.  IRDS 
standards  will  improve  the  quality  of  the  data  dictionary 
system  by  giving  users  extensibility  and  life-cycle  support, 
and  by  giving  vendors  a  common  basis  from  which  to  work. 
[Ref.  4:p.  7] 

B.  IRDS  IMPLEMENTATION  PLANNING 

Every  corporate  IRDS  implementation  is  unique.  The  type 
of  IRDS  (whether  active  or  passive,  dependent  or  independent)  , 
the  scope  of  the  IRDS,  the  organization's  information 
architecture,  and  the  structure  of  the  organization  itself 
contribute  to  this  uniqueness.  An  IRDS  implementation 
strategy  which  applies  100  percent  to  all  IRDS  implementations 
does  not  exist. 

However,  successful  IRDS  projects  share  some  common 
success  factors.  Together  these  elements  form  a  sound 
foundation  on  which  to  build  an  IRDS  implementation  strategy. 
In  the  following  sections  we  describe  minimum  conditions  which 


must  exist  and  actions  that  need  to  occur  before  attempting 
an  IRDS  implementation. 

1.  Management  Commitment 

The  condition  of  management  commitment  depicted 
earlier  for  Data  Administration  applies  here  as  well.  In 
addition,  under  public  and  private  program  support,  management 
commitment  must  include:  [Ref.  8:p.  55] 

-  Involvement  and  support  of  the  corporate  information 
systems  planning  process. 

-  Support  of  a  methodology  for  the  design,  development  and 
maintenance  of  information  systems.  Use  of  the  IRDS  in 
the  development  process  must  be  mandatory. 

-  Support  of  the  IRDS  as  the  only  source  for  data 
definitions  in  the  entire  organization. 

Management  commitment  to  the  implementation  of  an  IRDS 
is  critical  for  success.  Without  it,  IRDS  projects  should  not 
start . 

2.  End  User  Involvement 

The  use  of  the  IRDS  should  benefit  the  business  end 
users  as  well  as  the  MIS  users.  If  the  IRDS  only  services 
MIS  user  needs,  the  rest  of  the  organization  will  not  support 
the  IRDS.  Include  the  business  end-user  wherever  possible. 
For  example, 

...from  an  administrative  point  of  view,  a  strong  level 
of  understanding  and  support  for  the. . . (IRDS) . . . is 
crucial  to  its  success;  hence  as  many  persons  should 
participate  in  its  loading  and  maintenance  as  can 
reasonably  be  accommodated  by  the  system,  even  if  it  means 
sacrificing  some  quality  initially  [Ref.  8:p.  59]. 
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Moreover,  many  potential  users  may  refuse  to 
contribute  to  the  IRDS's  implementation  effort.  Lack  of 
understanding  of  the  IRDS's  purpose,  fear  of  change,  and  the 
extra  effort  required  to  start  an  IRDS  can  cause  this 
reluctance.  The  solution  for  winning  their  support  is  a 
thorough  training  program  that  demonstrates  the  benefits  of 
using  an  IRDS,  e.g.,  consistent  quality  of  documentation  and 
improved  communication. 

3.  Coordination  and  control 

IRDS  implementation  is  a  major  undertaking  which 
affects  many  components  of  the  organization.  As  such,  it 
requires  a  project  manager  for  centralized  coordination  and 
control  of  the  entire  project.  This  IRDS  Project  Manager 
needs  the  authority  to  coordinate  effort  across  a  wide  range 
of  organizational  boundaries.  Therefore,  proper  Project 
Manager  placement  in  the  organization  and  project  team 
composition  are  critical  for  success.  Figure  3  shows  a 
prescriptive  example  of  IRDS  Project  Manager  and  team 
placement  within  an  organization. 

The  IRDS  Project  Manager  is  a  senior  person  with  a 
team  consisting  of  representatives  from  the  various  business 
functions.  For  example,  in  Figure  3  TEAM  would  include  key 
personnel  from  VP  INVENTORY,  BP  SALES,  and  VP  IRM.  When  the 
project  is  complete,  day-to-day  operation  and  maintenance  of 
the  IRDS  passes  to  the  IRDS  Administrator  (IRDSA)  as  indicated 
by  the  dashed  line  in  Figure  3. 
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4.  Implementation  Plan 

An  implementation  plan  provides  the  framework  for 
griding  all  phases  of  the  IRDS  implementation.  It  is  the 
single  source  for  informing  all  levels  of  the  organization 
about  the  project  objectives,  benefits  sought,  and  a  general 
description  of  the  steps  necessary  for  implementation  of  the 
IRDS.  The  Project  Manager  is  responsible  for  the 
Implementation  Plan. 

The  implementation  plan  should. . .gain  management 
commitment,  provide  a  useful  service  to  end  users  and  MIS 
personnel,  have  the  controls  built  in  to  measure  the  level 
of  its  usefulness,  and  have  the  required  amount  of 
resources,  both  human  and  technology,  to  make  the  project 
a  success  [Ref.  8:p.  114]. 
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The  IRDS  is  part  of  a  larger  information  architecture 
designed  to  meet  the  needs  of  the  business.  The  Project 
Manager  should  establish  a  firm  relationship  in  the  plan 
between  the  strategic  Business  Objectives  and  the  IRDS 
implementation . 

Table  7  contains  the  minimum  steps  a  Project  Manager 
should  consider  when  formulating  an  IRDS  implementation  plan. 
Since  starting  an  IRDS  is  a  software  project.  Table  7  groups 
the  steps  into  appropriate  Systems  Development  Life  Cycle 
(SDLC)  phases  [Ref.  12:p.  163].  The  steps  themselves  consist 
of  ideas  from  Narayan  [Ref.  8],  Wertz  [Ref.  6],  Leon-Hong  and 
Plagman  [Ref.  13].  These  steps  are  not  sequential;  many 
actions  within  a  phase  may  occur  concurrently. 

The  steps  in  the  Analysis  Phase  determine  the  extent 
of  need  for  the  IRDS  (steps  A  through  C) ,  the  benefits  to  be 
gained  by  its  use  (steps  D  and  E) ,  and  the  scope  of  the  IRDS 
implementation  (step  F) .  The  Design  Phase  defines  the 
metastructures  of  the  IRDS  (steps  A  and  C)  ,  assigns  entity 
ownership  (step  B) ,  standardizes  naming  conventions  (step  D) , 
and  selects  the  appropriate  IRDS  for  the  project  (steps  E  and 
F)  .  Lastly,  the  Implementation  Phase  documents  the  procedures 
for  operating  the  IRDS  (steps  A,  B,  and  D) ,  and  details  the 
training  program  for  both  system  users  and  end  users  (step  C) . 
Here  also,  the  Project  Manager  should  review  the  plans  for 
implementing  applications  selected  for  IRDS  use,  e.g.,  how  the 
IRDS  will  integrate  with  the  SDLC  (step  E) . 
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TABLE  7 


IRDS  IMPLEMENTATION  PLANNING  8TEP8 


I.  ANALYSIS  PHASE 

A.  Identify  organizational  structure  and  existing 
practices 

B.  Review  existing  systems  and  system  interfaces 

C.  Interview  users  and  document  user  requirements 

D.  Analyze  IRDS  functions  and  user  requirements 

E.  Quantify  benefits 

F.  Prepare  functional  specifications 

II.  DESIGN  PHASE 

A.  Develop  entity  categories 

B.  Identify  individuals  responsible  for  entity 
categories 

C.  Establish  attributes  and  relationships 

D.  Develop  naming  conventions  for  each  entity 

E.  Develop  IRDS  evaluation  criteria 

F.  Select  an  IRDS 

III.  IMPLEMENTATION  PHASE 

A.  Develop  procedures  for  populating  the  IRDS 

B.  Develop  procedures  for  IRDS  update  and  maintenance 

C.  Develop  a  training  Package 

D.  Identify  security  procedures 

E.  Outline  activities  for  each  application  that  will 
be  implemented  under  the  IRDS 

F.  Choose  a  pilot  project 
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In  addition,  the  Implementation  Plan  should  propose 
a  specific  pilot  project  to  prove  the  value  of  using  an  IRDS 
(step  F) .  A  successful  pilot  implementation  will  greatly 
strengthen  management  and  end  user  support  for  further 
application  of  the  IRDS. 

To  demonstrate  control  to  higher  management  and 
engender  their  support,  the  Implementation  Plan  must  include 
the  identification  of  deliverables  for  each  major  activity. 
Furthermore,  the  plan  should  estimate  resources  needed  to 
produce  those  deliverables  and  set  target  dates  for  each  one. 
Table  8  lists  suggested  deliverables  from  each  phase. 

In  Table  8  the  Design  Phase  standards  refer  to  DA 
functions  such  as  setting  naming  standards,  key  word  and 
abbreviation  standards,  and  standards  for  writing  data  item 
definitions.  Standards  also  include  the  incorporation  of  IRDS 
maintenance  into  the  systems  development  methodology. 

The  Implementation  Phase  requires  many  procedures  for 
the  proper  operation  and  maintenance  of  the  IRDS.  Table  9 
lists  some  of  the  procedures  the  Project  Manager  should  ensure 
are  in  place  before  making  the  IRDS  operational  [Ref.  6:p. 
275]  . 

In  summary,  the  implementation  of  an  IRDS  requires 
strong  management  commitment  and  significant  end  user 
involvement.  A  project  manager  should  coordinate  and  control 
the  IRDS  implementation.  He  creates  and  uses  the 
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TABLE  8.  IRDS  IMPLEMENTATION  PLAN  DELIVERABLES 


I.  ANALYSIS  PHASE 

*  A.  Revised  Information  Systems  Architecture 

*  B.  Revised  IRM  strategic  planning  objectives 

C.  User  requirements 

D.  IRDS  cost/benefit  analysis 

E.  IRDS  functional  specifications 

II.  DESIGN  PHASE 

A.  Corporate  Data  Model 

B.  Logical  Data  Model 

C .  DA  Standards 

D.  Required  hardware  and  operating  system  software 

E.  Selected  IRDS 

III.  IMPLEMENTATION  PHASE 

A.  Physical  Data  Model 

B.  IRDS  installed 

C.  IRDS  populated 

D.  Procedures 

E.  Plans  for  running  applications  under  the  IRDS 

*  Not  required  if  IRDS  already  included 


TABLE  9.  IRDS  RELATED  PROCEDURES 


A.  Submission  and  processing  of  IRDS  maintenance 

B.  Deletion  of  data  that  is  no  longer  required 

C.  Control  of  back-up  files,  IRDS  restoration  and 
reorganization 

D.  Monitoring  space  utilization 

E.  Control  of  versions 

F.  Submission  and  processing  of  report  requests 

G.  Audit  and  correction  of  IRDS  contents 

H.  Migration  of  data  from  IRDS  to  IRDS  and  from 
test  status  to  production 

I.  Verification  of  consistency  between  IRDSs 

J.  Procedures  for  changing  Standards 
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implementation  plan  to  win  management  support  and  guide  the 
implementation . 

The  planning  steps,  deliverables  of  each 
implementation  phase,  standards,  and  procedures  discussed  in 
this  section  represent  minimum  requirements  for  a  successful 
IRDS  implementation.  These  requirements  as  well  as  the  IRDS 
standard  presented  in  the  first  section  of  this  chapter  are 
benchmarks  that  we  will  use  in  the  following  chapters  to  gauge 
the  status  and  extent  of  NAVSUP's  IRDS  implementation. 
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IV.  DATA  ADMINISTRATION  AND  IRDS  USE  AT  NAVSUP 


An  understanding  of  NAVSUP* s  information  systems 
environment  will  help  the  reader  view  our  findings  from  a 
clearer  perspective.  Therefore,  in  the  next  section  we 
describe  a  *'big  picture”  view  of  NAVSUP* s  organization  and 
its  strategic  directions  in  IRM.  Subsequent  sections  present 
the  data  collection  methodology  used  and  the  actual  findings 
of  the  study. 

A.  NAVSUP  ENVIRONMENT5 

Chapter  I  briefly  described  NAVSUP* s  mission.  Figure  4 
depicts  the  NAVSUP  command-level  organizational  structure  used 
to  provide  supplies  and  services  to  its  customers  worldwide. 
NAVSUP  consists  of  a  Headquarters  staff,  three  Inventory 
Control  Points,  eight  Navy  Supply  Centers,  four  Navy  Regional 
Contracting  Centers,  and  a  central  design  agency  (the  Fleet 
Material  Support  Office) .  NAVSUP  also  encompasses  the  Navy 
Resale  System,  the  Navy  Publishing  and  Printing  Service,  and 
several  other  field  activities  supporting  special  aspects  of 
the  NAVSUP  mission. 

Figure  5  shows  the  NAVSUP  headquarters-level  organization. 
It  is  important  to  observe  the  organization  level  of  the 

5Unless  otherwise  indicated,  the  information  for  this 
section  comes  from  the  Inventory  and  Information  Systems 
Development  Strategic  Plan  for  FY89  created  by  NAVSUP  04 . 
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Figure  4.  NAVSUP  Command-Level  Organization  [Ref. 


Figure  5.  NAVSUP  Headquarters-Level  Organization  [Ref. 


Deputy  Commander,  Inventory  and  Information  Systems 
Development  (SUP  04)  who  serves  as  the  Information  Resources 
Manager  for  NAVSUP,  relative  to  the  other  functional  area 
Deputy  Commanders. 

l.  NAVSUP  Organization  for  IRM 

The  Strategic  Planning  Board  (SPB)  provides  overall 
direction  for  NAVSUP  business  strategy  and  plans,  including 
information  systems  (see  Figure  6)  .  The  SPB  consists  of 
Deputy  Commanders  from  all  major  NAVSUP  mission  areas. 

The  Inventory  and  Information  Systems  Development 
Directorate  (SUP  04)  is  the  NAVSUP  organization  for  managing 
information  resources.  SUP  04's  responsibilities  include, 
but  are  not  limited  to:6 

-  Serving  as  NAVSUP 's  Information  Resources  Manager. 

-  Serving  as  the  focal  point  for  interaction  on  IRM  issues 
with  outside  organizations,  e.g..  Congress. 

-  Directing  and  managing  the  design,  development, 
implementation,  and  maintenance  of  assigned  NAVSUP 
sponsored  information  systems. 

-  Developing  and  submitting  NAVSUP* s  ADP  budget. 

-  Directing  NAVSUP* s  Data  Administration  Program. 

SUP  04  manages  or  functionally  sponsors  approximately  13 
military  and  71  civilian  personnel  at  Headquarters,  and  2,990 
field  personnel.  Also,  SUP  04  controls  roughly  $115  million 
in  Project  Funds,  $208  million  in  non-labor  costs,  and  an 


6For  a  complete  listing  of  SUP  04  *s  major  tasks  see 
Reference  1,  page  3-1. 
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information  systems  budget  of  $312  million  in  FY88  projected 
to  $372-400  million  in  out  years. 


Seven  divisions  comprise  SUP  04,  of  which  SUP  041, 
the  Information  Systems  Management  Division,  is  the  most 
relevant  to  this  study.  SUP  041’s  mission  is  to  provide 
NAVSUP  with  plans,  policies,  and  guidelines  for  managing  all 
NAVSUP  Information  Systems,  and  to  administer  ADP  Budgets. 
Also,  the  Data  Administrator  function  resides  within  this 
division.  We  will  discuss  the  DA  organization  in  greater 
detail  in  Section  C  of  this  chapter. 

Matrix  organizations  also  support  IRM.  For  example, 
the  Information  Systems  Steering  Committee  (ISSC)  consists  of 
SUP  04,  SUP  049  (Assistant  Deputy  Commander,  Inventory  and 
Information  Systems  Development) ,  and  SUP  04  Division 
Directors,  Project  Officers,  and  appropriate  functional 
representatives.  The  ISSC  reviews  Information  Systems  plans 
and  ensures  efficient  use  of  resources. 

2.  NAVSUP  Hardware  and  Software  Environment 

The  current  hardware  environment  includes  IBM  3090 
large  scale  mainframes,  Burroughs  4700  to  4900  mid-range 
mainframes,  and  Interdata,  Perkin  Elmer  and  Tandem 
minicomputers.  These  systems  run  automated  logistics  programs 
in  support  of  NAVSUP’ s  three  tier  supply  architecture.  [Ref. 
14 :p.  10] 

The  application  software  that  supports  each  tier  is 
different.  For  example,  at  the  top  level,  two  of  the 
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Inventory  Control  points  operate  under  Uniform  Inventory 
Control  Point  (UICP)  applications.  At  the  middle  level,  the 
Stock  Points  use  Uniform  Automated  Data  Processing  System  for 
Stock  Points  (UADPS-SP)  applications,  while  at  the  bottom 
level,  the  ships  and  squadrons  have  Shipboard  Uniform  ADP 
Systems  (SUADPS)  applications.  [Ref.  15:p.  62] 

These  systems,  along  with  various  office  automation 
systems,  share  a  complex  structure  of  short  haul  and  long  haul 
telecommunication  networks.  The  integration  of  all 
telecommunications  capabilities  is  called  the  NAVSUP  Logistic 
Network  (NLN)  architecture.7 

3.  NAVSUP  Strategic  Directions 

Three  of  NAVSUP' s  strategic  directions  pertain  to  this 
study.  The  first  is  the  modernization  of  its  key  information 
systems,  UICP,  UADPS-SP,  and  SUADPS  [Ref.  1:  p.  63].  The 
modernization  program's  g^al  is  to  improve  the  business 
functionality,  security  and  integrity  of  the  logistics 
management  systems.  Examples  of  how  NAVSUP  intends  to  realize 
this  goal  are: 

-  Replace  inadequate,  obsolete  information  technology  with 
appropriate  current  technology. 

-  Ensure  that  the  system  design  fully  implements  NAVSUP 's 
mission  requirements. 

7This  survey  of  NAVSUP' s  hardware  and  software 
environment  is  cursory.  For  a  more  thorough  description  of 
NAVSUP 's  Information  Systems  environment,  refer  to  Reference 
1,  pages  4-5  through  4-8. 


-  Ensure  that  the  requirements  of  each  functional  end  user 
of  the  system  are  met  through  continuous  involvement  of 
end  users  in  the  design,  development,  and  implementation 
process. 

-  Take  full  advantage  of  the  productivity  gains  inherent  in 
modern  system  design  and  development  tools. 

-  Ensure  that  modernization  efforts  result  in  improved  data 
integrity,  security,  and  inventory  accuracy. 

The  relevance  of  these  strategic  actions  will  become 
apparent  later  in  this  chapter  when  we  discuss  the  findings 
of  our  study. 

The  second  strategic  direction  is  the  explicit 
declaration  to  manage  information  as  a  resource.  To  this  end 
the  NAVSUP  global  business  model  serves  as  the  baseline  for 
reviewing  the  appropriateness  of  all  information  systems 
actions.  It  also  guides  the  data  administration  program  in 
identifying  areas  requiring  further  analysis  with  regard  to 
data  and  communication  architectures,  data  dictionaries, 
standardization,  and  so  forth.8 

The  third  strategic  direction  is  the  emphasis  of  data 
integrity  and  security  at  each  step  in  the  systems  development 
process.  As  discussed  earlier,  the  discipline  of  data 
administration  in  conjunction  with  its  primary  tool,  an 
Information  Resources  Dictionary  System,  can  contribute 
significantly  to  this  strategic  element. 


®To  view  the  NAVSUP  Global  Business  Model  see  Appendix 
B,  Figure  B-l. 
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4.  NAVSUP  Information  System  Architectures 

A  thorough  discussion  of  NAVSUP' s  information  systems 
architectures  is  beyond  the  scope  of  this  study.  However, 
Appendix  B,  NAVSUP' s  Strategic  Information  System 
Architectures  and  Guidelines,  provides  a  useful  perspective 
of:  (1)  the  scope  of  NAVSUP 's  effort  to  gain  control  of  its 
information  resources,  and  (2)  how  Data  Administration  and  an 
IRDS  fit  into  these  efforts. 

Working  within  the  NAVSUP  environment,  we  employed  a 
combination  of  methods  to  collect  data.  The  next  sections 
discuss  the  data  collection  methodologies  and  subsequent  data 
analysis. 

B.  DATA  COLLECTION  METHODOLOGIES 

We  employed  two  collection  methods  to  gather  information 
about  NAVSUP 's  Data  Administration  organization,  IRDS 
implementation  planning,  and  IRDS  use:  (1)  interviews,  both 
in  person  and  telephone,  and  (2)  a  mail  survey  conducted  under 
the  auspices  of  the  NAVSUP  Data  Administrator. 

The  in-person  interviews  required  travel  to  NAVSUP 
Headquarters  in  Crystal  City,  Virginia  and  to  the  Fleet 
Material  Support  Office  in  Mechanicsburg,  Pennsylvania. 
Through  the  in  person  interviews,  we  gained  a  general 
understanding  of  the  NAVSUP  DA  organization  while  meeting  some 
of  the  key  IRM  players.  Although  we  spent  most  of  the  time 
with  the  NAVSUP  and  FMSO  Data  Administrators,  and  IESC 
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personnel,  we  also  met  with  SUP  04  and  SUP  XD  separately  to 
discuss  DA  and  IRDS  concepts.  Additionally,  the  in-person 
interviews  provided  specific  data  about  DA  and  IRDS 
implementation  issues  and  problems.  Follow-on  telephone 
interviews  with  NAVSUP  and  FMSO  Data  Administration  personnel 
provided  verification  of  facts  and  answers  to  new  questions 
as  needed. 

The  mail  survey  completed  the  data  collection  effort.9  It 
provided  a  broad  range  of  information  on  Data  Administration 
and  IRDS  use  at  NAVSUP  and  subordinate  activities.  Questions 
on  the  survey  required  the  respondent  to  answer  with  one  word 
or  check  the  appropriate  block.  Short  answer  type  questions, 
when  used,  were  optional.  Also,  survey  respondents  did  not 
have  to  identify  themselves  or  their  activities.  This 
approach  encouraged  maximum  responses  and  frank  comments. 

Corporate  Data  Administration  surveys  conducted  by 
Gillenson  [Ref.  9]  in  1981  and  Kahn  [Ref.  5]  in  1982  guided 
the  selection  and  wording  of  questions  in  the  survey  which 
covered  the  following  categories: 

-  General  information  on  Data  Administration. 

-  DA  functions  and  responsibilities. 

-  Data  Dictionary  uses. 

-  DA  implementation  problems. 

-  Benefits,  perceived  or  real,  gained  from  DA  and  IRDS 
implementation . 


9 


See  Appendix  C  for  a  complete  list  of  questions  asked. 
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Only  NAVSUP  activities  with  a  Data  Administrator  assigned 
received  a  survey.  Seventeen  activities  met  this  criterion; 
of  those  seventeen,  eleven  responded  (64.7  percent),  thus,  the 
survey  results  do  not  constitute  a  scientific  sample. 

C.  DATA  ANALYSIS 

We  categorized  the  information  gained  from  interviews  and 
the  survey  under  the  three  primary  topics  of  this  study:  (1) 
NAVSUP  DA  implementation,  (2)  NAVSUP  IRDS  implementation 
planning,  and  (3)  NAVSUP  IRDS  implementation.  A  discussion 
of  the  data  collected  under  each  of  these  topics  follows 
below. 

1.  NAVSUP  DA  Implementation 

In  this  section,  we  compare  NAVSUP' s  Data 
Administration  program  (as  defined  by  the  data  gathered  and 
presented  here)  with  the  critical  success  factors  introduced 
in  Chapter  II  (refer  to  Table  2) .  This  comparison  results  in 
the  identification  of  DA  implementation  issues  and  problems 
at  NAVSUP. 

a.  Full  Management  Commitment 

Full  management  commitment  consists  of  three 
actions:  (1)  Adequate  budget  support  for  DA,  (2)  DA 
organizational  placement  high  enough  to  be  effective,  and  (3) 
Public  and  private  DA  program  support  by  management. 

Table  10  shows  the  NAVSUP  Headquarters  DA  budget 
for  the  last  four  years.  While  the  planned  budget  calls  for 
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TABLE  10.  NAVSUP  DA  BUDGET 


Planned 

Actual 

Percent  * 

FY86 

No  budget 

$34,000 

FY87 

$314,000 

$302,300 

96.2% 

FY88 

$314,000 

$202,000 

64.3% 

FY89 

$331,000 

$178,000  ** 

53.8% 

*  Actual 

as  a  %  of  Planned 

**Plus  $190,000 

deferred 

a  modest  5.4  percent  increase  in  a  three  year  period,  the 
actual  DA  budget  exhibits  a  significant  decreasing  trend. 
Conversations  with  SUP  041  confirmed  that  Department  of 
Defense  (DOD)  budget  cuts  caused  the  decline  in  actual 
funding.  SUP  041  also  projected  that  the  deferred  $190,000 
in  FY89  would  remain  deferred  throughout  FY89.  At  a  minimum, 
the  current  DA  budget  trend  shows  that  management's  immediate 
priorities  do  not  include  DA. 

Figure  1  illustrates  effective  placement  of  the 
DA  function  in  an  organization.  Figure  7  depicts  NAVSUP' s  DA 
organizational  position.  NAVSUP 's  DA  resides  two  layers 
beneath  the  Information  Resources  Manager  (SUP  04)  and  one 
layer  below  the  organizational  entities  whose  data 
administration  efforts  it  must  coordinate  (SUP  041  through 
SUP  048).  Interviews  with  the  NAVSUP  DA  (SUP  0414)  confirmed 
the  frustration  of  DA  goals  due  to  the  inability  to  influence 
senior  organizational  groups  to  cooperate  fully  with  DA 
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efforts.  For  example,  when  scheduling  information  engineering 
workshops  to  support  Strategic  Data  modeling,  there  was  no  top 
management  support  from  those  organizational  entities  involved 
in  NAVSUP's  modernization  projects.  Strategic  Data  Modeling 
succeeded  through  the  ability  of  the  NAVSUP  DA  to  obtain 
required  information  despite  lack  of  management  support  [Ref. 
15 :p.  75]. 

The  last  indicator  of  full  management  commitment 
is  public  and  private  DA  program  support.  Public  support  is 
evidenced  through  NAVSUP  Strategic  Plans,  publications,  and 
instructions  which  address  the  importance  of  managing  data  as 
a  resource.  However,  a  significant  number  of  the  survey 
respondents  (36  percent)  felt  that  management  support  was 
inadequate.  In  addition,  SUP  0414  believed  DA  lacked 
sufficient  management  support. 

Based  primarily  on  the  budget  support  and 
organizational  placement  of  the  DA  function,  we  conclude  that 
full  management  commitment  to  the  implementation  of  a 
successful  DA  program  does  not  exist. 

b.  Management  and  Organizational  Understanding 

Management  and  organizational  understanding  is 
made  possible  by:  (1)  relating  DA  concepts  to  business  goals, 
(2)  defining  DA  responsibilities  and  scope,  (3)  providing  the 
DA  with  the  authority  to  enforce  DA  policy,  and  (4)  having  a 
thorough  DA  education  and  training  program. 
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Figure  B-l  of  Appendix  B  depicts  the  global 
business  model  supporting  NAVSUP's  mission.  All  information 
systems  architectures  must  support  the  functions  or  processes 
in  this  business  model.  Thus,  the  business  needs  of  the 
organization  form  a  solid  foundation  for  NAVSUP's  data 
architecture  (Figure  B-2,  Appendix  B) . 

However,  the  two  primary  policy  documents  for 
establishing  the  NAVSUP  Data  Administration  Program,  NAVSUP 
Instruction  5231.1  [Ref.  16]  and  NAVSUP  Instruction  5231.2 
[Ref.  17],  inadequately  relate  the  DA  concept  to  NAVSUP's 
business  goals.  An  analysis  of  these  two  instructions  by 
American  Management  Systems,  Incorporated  in  January  1988 
revealed  the  following: 

As  stated  in  NAVSUPINST  5231.1,  the  objective  of  the 
NAVSUP  Data  Administration  Program  is  to  "enhance  mission 
performance  through  the  effective,  economic  acquisition 
and  use  of  information."  . . .However, . . .  policy  statements 
in  NAVSUPINST  5231.2  fail  to  carry  this  message  forward 
and  explicitly  state  what  each  policy  contributes  towards 
this  objective.... 

Thus  the  instructions  miss  an  opportunity  to  establish  DA 
based  on  a  business  foundation  which  would  nurture  program 
support  from  upper  management  and  other  organizational  groups. 
[Ref.  18 :p.  3-10] 

Clearly  defining  the  Data  Administrator's 
responsibilities  also  promotes  understanding.  NAVSUP 
Instruction  5231.1  explicitly  defines  the  roles  of  the  NAVSUP 
Data  Administrator,  the  FMSO  Data  Administrator,  the  Activity 
Data  Administrators,  and  the  Data  Administration  Advisory 
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Group.  Figure  8  portrays  the  organizational  relationships 
between  these  individuals. 10 

Additionally,  defining  the  scope  of  the  DA  program 
is  crucial  for  a  proper  understanding  of  it.  Although  the 
American  Management  Systems,  Inc.  report  rightly  criticized 
the  lack  of  defined  scope  in  NAVSUP  Instruction  5231.2  [Ref. 
10:p.  4-10],  SUP  04's  Strategic  IS  Architectures  and 
Guidelines,  Appendix  B  pages  103  through  109,  adequately 
outlines  the  scope  of  the  DA  program. 

To  effectively  implement  DA  policies  the  Data 
Administrator  needs  the  authority  to  enforce  them.  Upper 
management  assigns  this  authority  to  the  DA.  However, 
management  must  first  perceive  a  need  for  such  authority.  A 
thorough  understanding  of  DA  concepts  makes  management  aware 
of  the  necessity  for  this  authority  to  coordinate  and  control 
DA  efforts. 

The  survey  resulted  in  54.4  percent  of  the 
respondents  replying  that  the  Data  Administrator  had 
responsibility  without  the  corresponding  authority.  Interviews 
with  SUP  0414  reiterated  this  belief. 

Lastly,  a  thorough  DA  education  and  training 
program  is  the  single  most  important  contributor  toward 
achieving  management  and  organizational  understanding  of  DA. 


10For  a  complete  description  of  responsibilities  see 
NAVSUP  Instruction  5231.1,  enclosures  (3)  through  (6). 
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Figure  8.  NAVSUP  Data  Administration  '•rganization  [Ref.  15 :p 


.  66] 
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The  survey  results  confirm  the  need  for  education  and 
training: 

-  45.5  percent  of  the  survey  respondents  believed  management 
did  not  understand  DA  concepts. 

-  36.3  percent  of  the  respondents  felt  resistance  to  data 
sharing  by  users  and  systems  personnel. 

-  54.5  percent  of  the  respondents  reported  personnel 
resistance  to  job  responsibility  changes  caused  by  new  DA 
policies. 

Interviews  with  SUP  0414  revealed  that  top 
managers  received  a  series  of  executive  level  briefings  on  DA. 
SUP  0414  classified  some  as  disasters,  others  as  effective. 
The  briefers  themselves  had  to  adjust  the  contents  and  style 
of  the  briefs  to  better  suit  executive  needs.  However, 
despite  improved  delivery  techniques,  SUP  0414  still  believes 
management  requires  more  education  and  training  to  achieve  a 
full  understanding  of  the  need  for  DA. 

The  primary  vehicle  for  training  and  educating 
subordinate  commands  is  the  quarterly  meetings  of  the  Data 
Administrators  Advisor  Group  (DAAG) .  The  DAAG  includes  all 
Data  Administrators  assigned  to  NAVSUP  subordinate  activities. 
For  the  first  and  second  quarter  of  FY89,  budget  constraints 
forced  the  cancellation  of  the  DAAG  meetings,  hence,  much 
needed  training  did  not  take  place.11 

In  conclusion,  we  believe  NAVSUP' s  understanding 
of  DA  concepts,  i.e.,  management's  and  the  organization's,  is 

^Survey  respondents  indicated  45.5  percent  have  conducted 
some  form  of  DA  training  at  their  local  commands. 
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too  low  for  a  completely  successful  implementation  of  DA. 
However,  the  SUP  04  Strategic  Plan  provides  a  sound  framework 
from  which  a  better  understanding  of  DA  could  develop, 
c.  Appropriate  DA  Organisation 

The  last  of  the  three  critical  success  factors  for 
DA  implementation  is  an  appropriate  DA  organization.  An 
appropriate  DA  organization  consists  of:  (l)  adequate  number 
of  staff,  (2)  knowledgeable  and  experienced  DA  staff,  and  (3) 
a  realistic  workload  for  the  DA  staff. 

The  survey  grouped  adequate  staff  and 
knowledgeable  staff  into  one  question.  Not  surprisingly,  a 
significant  number  of  respondents,  45.5  percent,  believed  they 
suffered  from  a  lack  of  qualified  DA  staff.  Interviews  with 
the  SUP  0414  verified  the  difficulty  of  recruiting  experienced 
DA  staff.  Additionally,  the  current  austere  budget 
environment  makes  it  unlikely  that  NAVSUP  DA  organizations 
will  achieve  necessary  manning  levels  for  success. 

Interestingly,  only  two  of  the  eleven  respondents 
had  full-time  DAs.  Two  plausible  reasons  for  such  a  low 
number  of  full-time  DAs  are:  (1)  field  activities  simply  have 
not  acquired  the  budget  resources  necessary  to  support  full¬ 
time  DAs;  or  (2)  field  activities  do  not  perceive  the  need 
for  a  full-time  DA. 

Significantly  though,  one  of  the  full-time  DAs 
believed  that  DA  workloads  were  too  heavy.  The  workload  of 
the  DA  staff  must  match  their  capabilities.  Initial  goals 
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should  be  small  and  achievable.  This  builds  staff  experience, 
proves  DA  works,  and  builds  organizational  confidence  in  DA. 
A  pilot  project  approach  works  well  here.  Interviews  with  SUP 
0414  confirmed  the  need  to  identify  a  pilot  project  to  prove 
DA  concepts  work.  However,  as  yet,  SUP  0414  does  not  have  a 
pilot  project  assigned. 

Thus,  based  on  our  findings,  we  believe  that 
NAVSUP's  DA  organization  suffers  from  a  lack  of  qualified 
staff  and  an  unbalanced  workload.  Successful  DA  program 
implementation  depends  on  a  combination  of  NAVSUP's  ability 
to  attract  and  retain  qualified  DA  personnel,  and  to  assign 
realistic  workloads  to  achieve  DA  goals. 

In  summary,  the  three  critical  success  factors  for 
DA  implementation  are  (1)  full  management  commitment,  (2) 
management  and  organizational  understanding,  and  (3)  an 
appropriate  DA  organization.  Currently,  full  management 
commitment  to  DA  implementation  does  not  exist.  Also,  NAVSUP 
has  not  achieved  a  sufficient  level  of  management  and 
organizational  understanding  of  DA.  Lastly,  we  concluded  that 
NAVSUP  does  not  have  the  appropriate  DA  organization  in  place. 
We  believe  successful  DA  implementation  under  these  conditions 
is  not  feasible. 

2.  NAVSUP  IRDS  Implementation  Planning 

NAVSUP  refers  to  their  IRDS  as  the  Information 
Resources  Data  Dictionary/Directory  (IRDD/D) .  The  terms  IRDS 
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and  IRDD/D  are  synonymous.  The  last  section  in  this  chapter 
presents  the  differences  between  the  IRDS  standard  discussed 
in  Chapter  III  and  NAVSUP 's  IRDD/D. 

Here  we  compare  the  four  common  success  factors  for 
IRDS  implementation  planning  established  in  Chapter  III  with 
the  data  obtained  about  NAVSUP's  corporate  level  IRDS  project. 
The  four  success  factors  are:  (1)  management  commitment,  (2) 
end  user  involvement,  (3)  coordination  and  control,  and  (4) 
an  implementation  plan. 

a.  Management  Commitment 

Two  components  of  management  commitment,  budget 
support  and  program  support  (both  public  and  private) , 
discussed  earlier  under  DA  apply  here  as  well.  The  third, 
proper  organizational  placement  falls  under  the  coordination 
and  control  success  factor. 

IESC  is  currently  working  under  a  NAVSUP  contract 
to  complete  the  operational  logical  data  model.  Thus,  budget 
support  for  the  IRDD/D  implementation  project  is  adequate 
through  the  logicaj.  data  model  deliverable  of  the  design  phase 
(see  Table  8)  .  Since  NAVSUP  anticipates  completing  the 
operational  logical  data  model  design  in  the  last  quarter  of 
FY89,  funding  for  the  physical  database  design  and  IRDD/D 
implementation  will  most  likely  fall  under  the  FY90  budget. 
However,  the  high  probability  of  further  budget  cuts  in  FY90 
is  a  real  threat  to  the  project's  continuance. 
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Management  support  for  the  IRDD/D  project  is 
apparent  from  the  NAVSUP  strategic  directions  discussed 
earlier  in  this  chapter.  An  IRDD/D  is  the  key  to  attaining 
all  three  strategic  goals.  Furthermore,  the  frequent 
appearance  of  the  IRDD/D  in  SUP  04 's  Strategic  Plan  under  the 
guise  of  "Corporate  Data  Dictionary"  (CDD)  emphasizes 
management's  acceptance  and  support  of  the  IRDS  concept.  The 
Strategic  Plan  calls  for  the  use  of  the  IRDD/D  as  the 
authoritative  source  of  data  definitions  for  all  new 
information  systems  projects. 

However,  other  circumstances  exist  which  mitigate 
this  support.  For  example,  management  support  of  a 
methodology  for  the  design,  development,  and  maintenance  of 
information  systems  with  the  mandatory  use  of  an  IRDS  is 
critical  for  successful  IRDS  implementation.  Unfortunately, 
the  modernization  of  NAVSUP' s  major  automated  systems  began 
before  DA  and  the  IRDS  concept  existed  at  NAVSUP.  Retrofitting 
DA  techniques  and  the  IRDD/D  to  these  major  projects  is 
expensive,  extremely  complex  and  time  consuming.  Not 
surprisingly,  project  managers  resist  any  activities  that  may 
cause  a  slip  in  a  major  milestone.  Interviews  with  Sup  0414 
confirmed  this  resistance  significantly  hindered  initial 
acceptance  and  support  for  the  IRDD/D  project. 

Despite  this  resistance,  we  believe  that  NAVSUP 
management  commitment  to  the  IRDD/D  concept  is  strong. 
However,  NAVSUP  management  commitment  to  the  IRDD/D 


implementation  is  at  a  critical  crossroad.  The  continued 
funding  of  the  project  will  ultimately  reflect  the  extent  of 
management  *  s  commitment . 

b.  End  User  Involvement 

End  user  involvement  includes  three  components: 
(1)  the  IRDS  must  benefit  the  business  end  user,  (2)  the 
business  end  user  should  participate  in  the  creation  of  the 
IRDS,  and  (3)  an  end  user  training  program  should  strive  to 
overcome  fear  of  change,  lack  of  understanding,  and  promote 
end  user  benefits. 

The  NAVSUP  IRDD/D  will  derive  its  existence  from 
the  NAVSUP  Global  Business  Model  and  the  logical  data  model . 
The  Global  Business  Model  contains  the  processes  and  functions 
of  the  business  as  defined  by  the  business  end  user.  The 
IRDD/D  benefits  the  end  user  by  supporting  these  processes  and 
functions.  For  example,  a  business  end  user  desiring  to  know 
what  a  requisition  number  is,  its  composition,  and  what 
processes  and  functions  use  it,  could  query  the  IRDD/D  to 
obtain  this  information. 

As  stated  earlier  in  this  chapter,  the  continuous 
involvement  of  end  users  in  the  design,  development,  and 
implementation  process  will  ensure  that  the  IRDD/D  meets  end 
user  requirements.  Interviews  with  IESC  personnel  and  SUP 
0414  indicate  that  NAVSUP  functional  users  have  thus  far 
participated  in  every  step  of  the  IRDD/D  project. 
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What  is  not  clear,  though,  is  the  depth  of  end 
user  involvement.  We  found  no  signs  of  a  formal  training 
program  to  disperse  general  knowledge  of  the  IRDD/D's  purpose, 
use,  and  benefits  to  large  numbers  of  functional  end  users. 
Although  the  IRDD/D  is  still  in  the  design  phase,  it  is  not 
too  early  to  plan  the  preliminary  details  of  a  training 
program. 

We  believe  the  level  of  end  user  involvement  in 
the  IRDD/D  project  thus  far  is  sufficient.  Continued  end  user 
involvement  in  the  implementation  and  maintenance  stages  is 
critical  for  the  ultimate  success  of  the  IRDD/D  project.  A 
well  constructed  training  program  can  encourage  this  end  user 
involvement. 

c.  Coordination  and  Control 

The  successful  implementation  of  an  IRDS  depends 
on  proper  project  coordination  and  control.  The  three 
critical  elements  are:  (1)  the  right  project  manager,  (2) 
project  team  composition,  and  (3)  project  team  organizational 
placement. 

SUP  0414  serves  as  the  project  manager  for  the 
IRDD/D  implementation.  The  project  team  consists  of  IESC 
personnel,  the  DA  support  staff,  and  working  groups  from  each 
of  the  functional  areas.  The  team  reports  to  SUP  041. 

Interviews  with  SUP  0414  and  other  project  team 
members  indicate  that  they  lack  the  influence  with  the  Deputy 
Commanders  to  effectively  coordinate  the  project  (refer  to 
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Figure  5)  .  This  situation  is  similar  to  that  of  Data 
Administration  organizational  placement  discussed  previously 
in  this  chapter. 

We  believe  the  project  manager’s  lack  of  seniority 
and  the  project  team’s  low  organizational  placement 
significantly  decrease  their  political  clout.  Adequate 
political  influence  is  necessary  for  coordination  and  control 
across  all  functional  areas  at  the  directorate  level.  This 
situation  hinders  the  implementation  of  NAVSUP's  IRDD/D. 
d.  implementation  Plan 

An  implementation  plan,  as  described  in  Chapter 
III,  covers  a  broad  area  of  planning  activities  necessary  for 
guiding  all  phases  of  the  IRDS  implementation.  Interviews 
with  SUP  0414  and  other  DA  staff  members  revealed  that  a 
comprehensive  IRDS  implementation  plan  (in  the  format 
recommended  in  Chapter  III)  does  not  exist.  This  makes  direct 
comparisons  impractical.  Therefore,  we  present  a  comparison 
of  Chapter  Ill’s  IRDS  implementation  planning  steps  and 
deliverables  with  identifiable  actions  taken  by  NAVSUP  to 
date. 

The  first  goal  of  the  IRDS  Implementation  Plan  is 
to  relate  the  IRDS  implementation  to  strategic  business 
objectives.  As  stated  previously,  SUP  04 's  Strategic  Plan 
does  this  adequately. 

Next,  the  IRDS  Implementation  Plan  should  outline 
the  planning  steps  and  deliverables  for  each  SDLC  phase  (refer 
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to  Table  7).  The  Analysis  Phase  establishes:  (l)  the  extent 
of  need  for  the  IRDS,  (2)  the  benefits  gained  from  its  use, 
and  (3)  the  scope  of  the  IRDS.  NAVSUP  completed  steps  A 
through  D  and  step  F  of  the  Analysis  Phase  in  Table  7  by  two 
actions.  First,  the  study  by  AMS,  Inc.  established  the  need 
for  the  IRDS,  described  its  benefits,  and  identified  the 
requirement  to  define  its  scope  [Ref.  10:p.  1-1  and  1-2;  Ref. 
20:p.  4-3].  Second,  subsequent  efforts  by  the  NAVSUP  DA, 
IESC,  and  NAVSUP  functional  area  representatives  completed 
these  steps  [Ref.  15:p.  76]. 

However,  no  documentation  exists  supporting  the 
completion  of  quantifying  benefits  (step  E)  .  This  is  a 
difficult  step,  but  one  which  can  garner  management  support 
for  the  project  if  done  correctly. 

NAVSUP  is  currently  in  the  design  phase  of  the 
IRDS  implementation.  Interviews  with  IESC  personnel  and  the 
NAVSUP  DA  staff  confirmed  that  steps  A  through  D  of  the  design 
phase  are  part  of  the  design  effort  to  complete  the 
operational  logical  data  model.  Plans  to  develop  IRDS 
evaluation  criteria  (step  E)  and  select  an  IRDS  (step  F)  do 
not  exist. 

Furthermore,  under  the  implementation  phase,  we 
found  no  documented  plans  for  populating  the  IRDS  (step  A) , 
IRDS  update  and  maintenance  (step  B) ,  training  package  (step 
C) ,  and  security  procedures  (step  D) .  Conversations  with  SUP 
0414  indicated  an  awareness  of  the  need  for  such  plans. 
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However,  low  staffing  levels  prevented  their  creation  before 
the  implementation  phase. 


Lastly,  the  current  contract  with  IESC,  which 
includes  creation  of  procedure  models  for  application  systems, 
covers  step  E.  Also,  as  stated  previously,  NAVSUP  has  not 
identified  a  pilot  project  (step  F) . 

The  implementation  plan  should  also  include  the 
deliverables  in  each  phase  identified  in  Table  8.  Under  the 
Analysis  Phase,  NAVSUP' s  Information  Systems  Architecture  and 
IRM  Strategic  Plan  already  include  the  IRDD/D  (alias  the  ODD) 
as  part  of  NAVSUP' s  overall  planning  objectives.  User 
requirements  (deliverable  C)  and  IRDS  functional 
specifications  (deliverable  E)  resulted  from  the  efforts 
described  above  concerning  the  Analysis  Phase  steps.  However, 
we  found  no  indication  of  an  IRDS  cost/benefit  analysis. 

Under  the  Design  Phase,  IESC  completed  the 
Corporate  Data  Model.  Currently,  they  are  working  on  the 
Operational  Logical  Data  Model  scheduled  for  completion  by 
June  1989.  DA  standards  (deliverable  C)  exist  to  a  limited 
extent  in  NAVSUP  Publication  509,  (Official  Title),  which 
deals  with  data  naming  conventions.  However,  SUP  0414  and  DA 
staff  report  NAVSUP  Publication  509  needs  a  significant 
revision  to  bring  it  up  to  date. 

Only  two  other  deliverables  have  been  planned,  and 
those  only  partially.  NAVSUP  contracted  IESC  to  create  the 
specifications  of  physical  data  characteristics.  These 
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specifications  will  be  the  foundation  for  the  Physical  Data 
Model,  deliverable  A  under  the  Implementation  Phase.  Also, 
IESC  is  to  create  procedure  models  for  application  systems. 
These  procedure  models  are  part  of  the  plans  for  running 
applications  under  the  IRDD/D,  deliverable  E  of  the 
Implementation  Phase. 

In  summary,  NAVSUP  has  achieved  many  of  the  IRDS 
implementation  steps  and  deliverables  outlined  in  Chapter  III, 
despite  not  having  a  comprehensive  IRDS  Implementation  Plan. 
However,  we  believe  the  lack  of  a  comprehensive  IRDS 
implementation  plan  significantly  jeopardizes  the  IRDD/D 
implementation . 

Without  such  a  plan,  directly  linking  the  IRDD/D 
to  business  objectives  and  demonstrating  project  control  to 
management  is  difficult  at  best.  This  situation  does  not 
engender  management  support  for  the  project.  Lack  of 
management  support  partially  explains  the  low  organizational 
placement  of  the  IRDS  project  team  and  the  unstable  funding 
environment  for  the  project. 

Additionally,  without  a  framework  for  guiding  all 
phases  of  the  IRDS  implementation,  there  is  always  the  danger 
of  overlooking  a  critical  step  in  the  development  process. 
Such  an  oversight  can  create  serious  unforeseen  problems 
later. 

The  next  section  compares  the  major  concepts  of 
the  NBS  IRDS  standard  with  the  design  of  the  IRDD/D. 


74 


3.  NAVSDP  IRDD/D  Implementation 

As  stated  in  the  NAVSUP  Strategic  Plan,  NAVSUP  must 
remain  in  a  position  to  take  advantage  of  modern  information 
technology  such  as:  [Ref  l:p.  6-9] 

-  Data  and  processing  distribution. 

-  The  growing  power  and  efficiency  of  relational  data  base 
technology. 

-  Intelligent  work  stations  (IWS)  in  the  hands  of  end  users 
throughout  the  supply  system  including  managers  and 
executives . 

-  Intelligent  network  capabilities. 

-  Artificial  intelligence. 

In  support  of  this,  NAVSUP  operates  a  logical  three-tier 
information  processing  architecture.  The  three  tiers  are: 
Production,  Departmental,  and  End  User.  Table  11  provides 
examples  of  data  and  applications  to  be  resident  in  the  three- 
tier  architecture. 

Three  conceptual  views  of  the  CDD  are  near  term,  mid 
term,  and  long  term.  In  the  near  term,  the  current  NAVSUP 
state,  the  IRDD/D  will  interface  with  the  existing 
Modernization  Reference  Dictionary  (MODDICT) ,  as  shown  in 
Figure  9.  We  discuss  MODDICT  in  more  detail  later  in  this 
chapter.  The  IRDD/D  interacts  with  MODDICT  in  the  Production 
Environment  only.  As  Table  11  shows,  shared  data  is  centrally 
managed  and  maintained. 
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In  the  mid  term,  the  IRDD/D  interfaces  with  the 
Production  Environment  and  the  DSS  environment.  Figure  10.  At 
this  stage,  applications  include  ad  hoc  query  and  transaction 
preparation. 

The  long  term  concept,  Figure  11,  shows  the  CDD  and 
its  interaction  with  all  levels  of  the  three  tier 
architecture.  Applications  include  Decision  Support  Systems 
for  the  End  User,  and  transaction  and  documentation 
preparation. 


TABLE  11.  THREE-TIER  ARCHITECTURE  [Ref.  l:p.  6-9] 


TIER 

TYPE  DATA 

TYPE  APPLICATION 

Production 

-Corporate  shared  raw 

-Data  establishment  and 

data 

change 

-Data  derived  for 

-Centrally  managed  and 

production 

maintained 

-Historical  data 

-Process  carried  to 
logical  conclusion 

Departmental 

-Corporate  download 

-Data  use/manipulation 

augmented  with 

-Transaction 

additional/derived 

preparation 

data 

-Ad  hoc  query 
represents  process 
controls 

-Document  storage 
distribution 

End  User 

-Specialized  download 

-Decision  support 

-Derived  data 

systems 

-Personal  data 

-Transaction  and 
documentation 
preparation 
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Figure  11.  Long  Term  Concept 


An  existing  contract  with  IE SC  provides  a  continuing 
effort  that  supports  the  development  of  NAVSUP's  IRDD/D.  In 
1988,  American  Management  Systems  (AMS),  Inc.  published  the 
results  of  a  detailed  study  of  NAVSUP's  CDD  requirements  and 
alternatives  [Ref.  18 :p.  3-1].  Custom  development  of 
dictionary  software  was  the  alternative  selected  by  NAVSUP  to 
satisfy  its  IRDD/D  requirements. 

Chapter  III  discussed  the  recently  approved  NBS 
Information  Resource  Dictionary  System  standard.  We  will 
compare  development  of  the  NAVSUP  IRDD/D  with  key  concepts  of 
the  NBS  standard.12 

1 .  Core  Module 

a.  Schema 

The  IRDD/D  will  include  the  ability  to  control 
and  regulate  access  to  the  IRDD/D  and  the  IRDD/D  Schema.  It 
will  not  include  a  facility  to  automatically  document  audit 
information  about  changes  to  the  IRDD/D  and  the  IRDD/D  Schema. 

b.  Life-Cycle-Phases 

The  capability  to  construct  partitions  in  the 
IRDD/D  that  correspond  to  life-cycle-phases  will  exist.  The 
IRDD/D  will  include  the  potential  to  categorize  life-cycle- 
phases  . 


The  comparison  of  the  NBS  IRDS  features  with  the  ongoing 
design  of  NAVSUP's  IRDD  is  based  on  a  series  of  telephone 
interviews  with  George  Miller,  SUP  04142,  and  Francis  Barnett, 
Consultant,  IESC  representative,  during  February  1989. 
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o.  Versioning 

A  facility  to  assign  different  types  of  names  will 
exist.  Primary  identifiers  will  have  version-identifiers. 
Version-identifiers  can  consist  of  a  variation-name  and  a 
revision-number.  The  IRDD/D  will  allow  descriptive-names.  It 
will  allow  duplicate  access-names  and  descriptive-names 
throughout  the  IRDD/D. 
d.  Views 

A  facility  to  define  IRDD/D-views  and  IRDD/D- 
schema-views  will  exist.  An  IRDD/D-schema-view  will  include 
a  set  of  meta-entities,  meta-attributes,  and  meta¬ 
associations. 

2.  Basic  Functional  Schema 

There  will  be  no  defined  Basic  Functional  Schema  in 
the  IRDD/D,  however,  defined  entities,  attributes,  and 
associations  will  be  more  comprehensive.  The  IRDS  "starter 
sets"  will  be  subsets  of  IRDD/D  defined  entities,  attributes, 
and  associations. 

3.  IRDS  Security 

The  IRDD/D  will  contain  an  access  control  facility. 
Create,  Read,  Update,  and  Delete  (CRUD)  values  will  define 
the  access  level  to  the  IRDD/D  and  IRDD/D  Schema.  There  will 
be  no  separate  Entity-Level  Security  as  read  or  write  locks 
for  individual  entities. 
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4.  Extensible  Life-Cycle-Phase  Facility 

The  IRDD/D  will  not  include  the  ability  to  designate 
hierarchical  relationships  among  phases.  Phase-related 
associations,  where  the  first  entity  in  the  association  is 
dependent  on  the  second  entity,  while  the  second  entity  is 
independent  of  the  first,  will  exist.  Integrity  rules  for 
moving  an  entity  between  life-cycle  phases  will  exist. 

5.  Procedure  Facility 

The  capability  to  define  and  execute  IRDD/D 
procedures,  or  macros  will  not  exist. 

6.  Application  Program  interface 

An  interface  between  standard  programming  languages 
and  the  command  language  of  the  IRDD/D  will  exist.  A  facility 
will  exist  to  enforce  integrity  and  security  rules. 

7.  Services  Interface 

The  initial  version  of  the  IRDD/D  will  not  contain 
this  feature.  Future  versions  will  allow  external  software 
direct  access  to  the  IRDD/D  and  IRDD/D  Schema. 

Many  features  of  the  NBS  IRDS  standard  are  currently 
being  incorporated  in  the  design  of  the  NAVSUP  IRDD/D. 
Significant  IRDD/D  features  that  differ  from  the  IRDS  standard 
include: 

-  The  inability  to  automatically  document  audit  information 
concerning  changes  to  the  IRDD/D  and  IRDD/D  schema. 

-  The  ability  to  duplicate  access-name  and  descriptive-names 
throughout  the  IRDD/D. 

-  The  inability  to  designate  hierarchical  relationships 
among  life-cycle-phases. 
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-  The  inability  to  define  and  execute  IRDD/D  procedures  or 
macros . 

While  NAVSUP  develops  the  IRDD/D,  NAVSUP's  Central 
Design  Agency,  FMSO,  continues  to  improve  MODDICT.  MODDICT 
also  known  as  NAVSUP  PUB  562,  is  the  FMSO  command  dictionary. 
It  is  the  central  reference  source  for  data  about  NAVSUP 
developed  systems.  It  includes  only  data  from  modernized 
systems.  MODDICT  contains  data  elements  extracted  from 
multiple  logical  design  dictionaries  such  as  SPAR,  UICP,  and 
MARP.  Initial  population  occurs  when  logical  design 
dictionaries  export  data  elements  and  their  characteristics 
to  MODDICT.  [Ref.  19:p.  2-1] 

MODDICT  serves  as  one  of  the  tools  used  by  system 
developers.  There  exists  a  draft  Requirements  Statement  for 
MODDICT  expansion.  The  draft  provides  a  communications  vehicle 
for  FMSO  system  developers  and  end  users  to  review  the 
requirements  for  expansion.  The  draft  expansion  includes  a 
requirement  to  structure  MODDICT  to  conform  to  the  NBS  IRDS 
standards.  [Ref.  19 :p.  2-2] 

MODDICT  plays  an  important  role  for  system  designers 
at  FMSO.  Structuring  MODDICT  to  conform  to  the  NBS  IRDS 
standard  will  assist  in  eventual  IRDD/D  implementation.  We 
believe  that  the  design  of  the  NAVSUP  IRDD/D  should  conform 
to  the  NBS  IRDS  standard  in  all  respects.  Though  the  NBS 
standard  is  not  mandatory,  "Turnkey  Systems"  traditionally 
conform  to  the  standards.  It  is  doubtful  that  an 
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organization  as  complex  as  NAVSUP  will  ever  operate  under  one 
software  environment.  Designing  a  corporate  tool  that  will 
interface  with  numerous  vendor  products  will  help  ease  future 
interface  problems. 

In  the  next  chapter,  we  present  solutions  and 
guidelines  for  the  resolution  of  the  problems  identified  in 
the  study. 


83 


V.  RECOMMENDATIONS  AND  CONCLUSIONS 


In  this  study,  we  used  a  three  pronged  approach  for 
analyzing  a  subset  of  the  IRM  infrastructure  at  NAVSUP. 
Specifically,  we  studied  NAVSUP 1 s:  (1)  implementation  of  DA, 
(2)  IRDS  implementation  planning,  and  (3)  actual  IRDS 
implementation.  The  study  identified  problems  and  issues 
hindering  successful  implementation  of  this  IRM  subset  at 
NAVSUP.  Below,  we  summarize  these  problems  and  issues,  and 
offer  recommendations  to  resolve  the  most  significant  ones. 

A.  NAVSUP  DA  IMPLEMENTATION  ISSUES  AND  RECOMMENDATIONS 

Full  management  commitment,  management  and  organizational 
understanding  of  DA  concepts,  and  a  strong  DA  organization 
form  the  foundation  of  a  sound  Data  Administration  program. 
Our  study  results  show  that  the  NAVSUP  DA  program  is  weak  in 
each  of  these  a’-eas. 

The  key  to  successful  DA  implementation  is  management 
understanding  of  DA  concepts.  Management  understanding  paves 
the  way  for  management  commitment.  Management  commitment 
makes  a  strong  DA  organization  possible  by  allocating 
sufficient  resources  to  support  the  DA  program.  Therefore, 
we  recommend  that  NAVSUP  do  the  following: 

-  The  NAVSUP  Strategic  Plan,  NAVSUP  Instruction  5231.1  and 
NAVSUP  Instruction  5231.2  should  use  the  same  terms  and 
acronyms  to  describe  the  DA  program.  Each  document  should 
support  the  other  in  establishing  links  between  DA 
concepts  and  the  business  goals  of  the  organization. 
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Consistent  use  of  terms  and  a  strong  orientation  toward 
business  goals  will  foster  management  and  organizational 
understanding  of  DA  concepts. 

-  The  Data  Administration  Advisory  Group  (DAAG)  meetings  are 
an  excellent  vehicle  for  expanding  the  organization's 
level  of  awareness  of  DA  concepts,  issues,  and  problems. 
Organizational  DA  awareness  is  an  education  process  which 
can  take  several  years  to  obtain.  Since  NAVSUP  is  in  the 
early  stages  of  establishing  a  DA  program,  now  is  the 
right  time  to  start  the  education  process.  NAVSUP  should 
not  wait  until  major  systems  requiring  DA  skills  are  on¬ 
line  before  developing  the  necessary  DA  awareness  and 
skills  to  manage  them,  e.g.,  SPAR.  By  then,  it  will  be 
too  late. 

-  The  DA  group  must  exist  on  an  organizational  level  where 
it  can  effectively  coordinate  DA  efforts  across  all 
organizational  boundaries.  At  a  minimum,  NAVSUP' s  DA 
group  should  report  directly  to  SUP  04 .  The  Data 
Administrator  should  be  a  GS-15.  Under  this  arrangement, 
SUP  04  would  provide  the  political  influence  to  seek 
support  for  the  DA  program  from  the  other  directorates. 

-  As  a  minimum,  the  DA  budget  should  adequately  support  the 
DA  staff,  the  creation  of  a  DA  education  and  training 
program,  the  DAAG  quarterly  meetings,  and  the  creation  and 
implementation  of  the  IRDD/D. 


B.  NAVSUP  IRDS  IMPLEMENTATION  PLANNING  ISSUES  AND 

RECOMMENDATIONS 

Successful  IRDS  implementation  planning  requires  four 
elements:  (1)  management  commitment,  (2)  end  user 

involvement,  (3)  project  coordination  and  control,  and  (4)  an 
implementation  plan.  Study  results  indicate  the  first  two 
elements  are  adequate  at  NAVSUP  for  the  IRDS  implementation 
(assuming  continued  budget  support) .  However,  the  third 
element  is  significantly  frail  and  the  fourth  element  non¬ 
existent.  We  recommend  NAVSUP  take  the  following  actions: 

-  The  implementation  of  an  IRDS  requires  assimilated 
knowledge  and  coordination  from  all  areas  of  the 
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organization.  We  believe  a  matrix  organization13  is  the 
best  structure  for  the  IRDD/D  implementation  team.  A 
matrix  organization  is  an  excellent  mechanism  for 
undertaking  and  accomplishing  complex  projects.  Such  a 
structure  stimulates  interdisciplinary  cooperation  and 
motivates  people  to  identify  with  the  end  product.  [Ref. 
21 :p.  254-255]  The  Project  Manager  should  have  a 

functional  background  to  ensure  the  IRDD/D  meets  NAVSUP's 
mission  needs.  He/she  should  be  a  GS-15  or  mid-grade  0- 
6  who  reports  directly  to  SUP  00X. 

-  In  addition,  the  Project  Manager  should  have  two 

assistants:  the  NAVSUP  DA  for  data  administration 

expertise  and  the  DBA  from  the  IRDD/D  implementation  site 
for  technical  proficiency.  This  management  group  should 
draw  its  team  from  the  DA  staff,  private  contractor,  and 
representatives  from  each  functional  area. 

-  The  IRDD/D  implementation  Project  Manager  should  create 
a  comprehensive  Implementation  Plan.  The  plan  should 
outline  the  tasks  and  specify  the  deliverables  of  each 
phase  of  the  SDLC.  Moreover,  the  plan  should  relate  the 
IRDD/D  project  directly  to  NAVSUP's  business  plans  and 
mission  needs.  In  addition,  SUP  OO  should  approve  the 
plan. 


C.  NAVSUP  IRDD/D  IMPLEMENTATION  ISSUES  AND  RECOMMENDATIONS 

The  IRDD/D  is  at  the  pinnacle  of  a  planned  hierarchy  of 
dictionaries  that  will  exist  to  support  NAVSUP's  three  tier 
information  systems  architecture  (refer  to  Figure  B-3, 
Appendix  B) .  The  success  of  this  architecture  hinges  on  each 
dictionary's  ability  to  communicate  with  the  dictionaries  on 
the  other  levels. 

Currently,  IESC  is  designing  a  generic  IRDD/D. 
Implementation  of  this  generic  IRDD/D  could  occur  under  most 


13A  matrix  organization  is  an  organizational  structure  in 
which  each  employee  reports  to  both  a  functional  manager  and  a 
project  manager.  [Ref.  21:pp.  251-255]  provides  a  more  thorough 
description  of  a  matrix  organization. 
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relational  DBMSs,  e.g.,  DB2  or  Oracle.  We  recommend  that  the 
design  and  implementation  of  the  IRDD/D  adhere  to  the  IRDS 
standard  presented  in  Chapter  III  for  the  following  reason: 
NAVSUP's  information  systems  architecture  consists  of  diverse, 
geographically  dispersed  systems.  No  IRDS  exists  now  which 
is  compatible  with  all  of  NAVSUP's  information  systems. 

However,  the  NBS  IRDS  Standard  establishes  the  framework 
for  the  creation  of  such  an  IRDS.  Since  commercial  vendors 
participated  heavily  in  the  formulation  of  the  NBS  IRDS 
Standard,  we  believe  it  is  only  a  matter  of  time  (2-4  years) 
before  a  commercial  product  reaches  the  market  that  can  meet 
NAVSUP's  environmental  needs. 

D.  CONCLUSIONS  AND  AREAS  FOR  FURTHER  RESEARCH 

1.  conclusions 

While  viewing  the  extent  and  depth  of  DA  and  IRDS  use 
at  NAVSUP  and  its  subordinate  commands,  one  implementation 
factor  continually  stood  out:  organizational  change.  As 
discussed  previously,  DA  is  a  relatively  new  management 
discipline  compared  to  areas  such  as  finance  or  inventory, 
and,  IRM  is  even  more  recent.  Historical  information  to  guide 
IRM  and  DA  implementation  is  scant.  However,  we  believe  two 
points  are  clear  from  the  evolution  of  IRM  and  DA.  First, 
organizations  must  view  information  as  a  resource  requiring 
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management.  Second,  structural  changes  to  the  organization 
are  necessary  to  implement  the  infrastructure  needed  to 
support  the  management  of  information. 


This  study  furnished  evidence  of  NAVSUP's  plan  to 
manage  information  as  a  resource.  In  addition,  it  provided 
suggestions  for  creating  the  infrastructure  to  support  a 
subset  of  IRM  at  NAVSUP,  specifically  DA  and  the  use  of  an 
IRDS .  This  study  also  offered  guidelines  for  the 
implementation  of  a  DA  program,  planning  an  IRDS 
implementation,  and  establishing  an  IRDS. 

2.  Areas  for  Further  Research 

During  the  course  of  this  study,  we  identified  three 
areas  of  interest  which  require  further  research.  First, 
NAVSUP's  target  information  systems  architecture  calls  for  a 
hierarchy  of  data  dictionaries.  The  physical  implementation 
deta-xs  for  such  a  hierarchy  do  not  currently  exist.  Part  of 
the  reason  for  this  is  the  technology  lag  in  IRDSs  discussed 
earlier.  A  future  study  could  track  the  progress  of  IRDS 
technology  and  propose  or  design  the  actual  physical 
implementation  of  NAVSUP's  IRDS  hierarchy. 

Second,  the  long  term  question  of  whether  NAVSUP 
should  implement  an  active  IRDD/D  versus  the  passive  IRDD/D 
could  be  addressed.  Further  research  could  establish 
appropriate  criteria  for  the  determination  of  which  IRDSs  in 
NAVSUP's  IRDS  hierarchy  should  be  active  and  which  should  be 
passive.  An  additional  objective  of  such  a  study  could  be  to 


88 


develop  a  strategy  for  converting  passive  IRDSs  to  active 
IRDSs . 

Third,  NAVSUP  information  systems  must  have  the 
capability  to  communicate  with  other  NAVY  and  DOD  components. 
A  future  study  could  address  the  issue  of  how  NAVSUP 's  IRDD/D 
will  interface  with  outside  information  systems. 
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APPENDIX  A 


ADP 

AMS 

CDD 

CRUD 

DA 

DAAG 

DBA 

DBMS 

DOD 

DSS 

FIPS 

FMSO 

ICP 

IESC 

IRD 

IRDD/D 

IRDS 

IRDSA 

IRM 

IS 

ISSC 

IWS 


LIST  OF  ABBREVIATIONS 

Automated  Data  Processing 
American  Management  System,  Inc. 

Corporate  Data  Dictionary 

Create,  Read,  Update,  Delete 

Data  Administration 

Data  Administrators  Advisor  Group 

Data  Base  Administrator 

Data  Base  Management  System 

Department  of  Defense 

Decision  Support  System 

Federal  Information  Processing  Standard 

Fleet  Material  Support  Office 

Inventory  Control  Point 

Information  Engineering  Systems  Corporation 
Information  Resource  Dictionary 
Information  Resource  Data  Dictionary/Directory 
Information  Resource  Dictionary  System 
IRDS  Administrator 
Information  Resource  Management 
Information  System 

Information  Systems  Steering  Committee 
Intelligent  Work  Stations 
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MARP 


MIS 

MODDICT 

NAVFSSO 

NAVSUP 

NBS 

NDL 

NLN 

NSC 

PRA 

SDLC 

SPAR 

SPB 

SQL 

SUADPS 

SUP  XD 

SUP  00 

SUP  00X 

SUP  04 

SUP  0414 
SUP  049 

UADPS-SP 

UICP 


Missile  ADP  Replacement  Program 

Management  Information  System 

Modernization  Reference  Dictionary 

Navy  Food  Service  Systems  Office 

Naval  Supply  Systems  Command 

National  Bureau  of  Standards 

Network  Data  Language 

NAVSUP  Logistic  Network 

Naval  Supply  Center 

Paperwork  Reduction  Act 

Systems  Development  Life  Cycle 

Stock  Point  ADP  _ iacement 

Strategic  Planning  Board 

Structured  Query  Language 

Shipboard  Uniform  ADP  systems 

Director,  Vertical  Integration  Project 

Commander,  Naval  Supply  Systems  Command 

Assistant  Commander,  Inventory  and  Systems 
Integrity 

Deputy  Commander,  Inventory  and  Information 
Systems  Development 

NAVSUP  Data  Administrator 

Assistant  Deputy  Commander,  Inventory  and 
Information  Systems  Development 

Uniform  Automated  Data  Processing  System  for 
Stock  Points 

Uniform  Inventory  Control  Point 
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APPENDIX  B 

VI.  STRATEGIC  INFORMATION  SYSTEM  ARCHITECTURES  AND  GUIDELINES 


This  section  of  NAVSUP's  plan  provides  the  bridge  between  the 
business -type,  manageroent-by-objectives  discipline  contained  in 
the  preceding  sections  and  the  technical  aspects  of  information 
systems  planning  required  for  systems  development  that  follows  in 
section  VII. 

Much  of  the  conceptual  framework  for  this  section  of  the  plan 
comes  from  an  article  by  Devlin  and  Murphy  in  the  IBM  Systems 
Journal,  Vol  27,  No  1,  1988.  Figure  1  is  the  overall  Information 
System  Architecture  that  forms  the  basis  of  our  information 
systems  planning  and  provides  a  rational  envelope  within  which  to 
develop  coordinated,  supportive  information  systems. 

The  uppermost  level  of  figure  1  includes  the  NAVSUP  Strategic 
Plan  and  the  DON  Information  Resources  Strategic  Plan,  which 
includes  the  Functional  Sponsors’  Plans,  and  provides  overall 
business  and  information  resources  management  strategies. 

The  next  three  levels  of  the  overall  architecture  are  discussed 
in  detail  beginning  with  paragraph  A,  below.  Each  Information 
Processing  Architecture  is  accompanied  by  Guidelines  to  be  used 
for  information  systems  development  and  thereby  achieve  a 
cohesive  organization  of  systems. 

The  last  level  of  the  overall  architecture  is  reflected  in 
Section  VII,  Information  Requirements  Plans  beginning  on  page 
7-1. 


A.  INFORMATION  SYSTEMS  STRATEGIES 

This  paragraph  discusses  the  three  information  system  strategies 
shown  in  the  second  level  of  the  overall  Information  System 
Architecture,  figure  1. 

1.  BUSINESS  MODE!  AND  INFORMATION  FLOW 

The  Chief  of  Naval  Operations  designated  the  Commander,  Naval 
Supply  Systems  Command  as  the  steward  for  supply  functions 
throughout  the  Navy.  Supply  is  pervasive.  Virtually  every 
organization  within  the  Navy,  as  well  as  many  contractors, 
perform  some  level  or  aspect  of  supply. 

a.  NAVSUP'S  mission  is  to  develop,  manage  and  operate 
the  Navy  Supply  System  to  provide  supplies  and  services  to 
satisfy  peacetime  and  wartime  fleet  and  other  customer  mission 
requirements  (source:  NAVSUP  STRATEGIC  PLAN). 

b.  Business  process  and  information  architectures  or 
models  are  required  for  understanding  the  business  functions  and 
the  information  required  to  support  that  mission  and  are  the 
logical  starting  point  for  information  systems  technical 
planning. 
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(1)  The  business  model  supporting  NAVSUP' s  mission 
is  depicted  by  figure  2.  Supply  macro  function  definitions  are 
contained  in  appendix  A. 

(2)  The  strategic  information  categories  required  by 
supply  functions  are  shown  by  figure  3. 

c.  The  hierarchy  of  effort  in  the  business  model  is: 
Mission,  Function,  Process,  and  Activity/Task.  The  intent  of  the 
hierarchy  is  to  provide  management  flexibility  and  production 
change  opportunity  at  the  activity/task  level  while  keeping 
stability  at  the  mission/function/process  level. 

d.  The  single  manager  within  NAVSUP  for  each  process  is 
indicated  in  the  next  to  last  column  of  figure  2.  For  some 
processes,  managers  outside  of  NAVSUP  have  Navy-wide 
responsibilities;  those  managers  are  indicated  in  the  last  column 
of  figure  2. 


e.  NAVSUP  headquarters  will  be  the  arbitrator  in  any 
functional  ownership  contentions. 

2 .  TECHNOLOGY  PROJECTIONS 

a.  The  following  are  attributed  to  Information  Week, 
January  19,  1987.  In  general,  they  apply  to  the  NAVSUP 
environment  as  well. 

(1)  Strategic  Networking.  Reliance  on  and 
investment  in  the  strategic  potential  of  electronically 
transmitted  data,  voice,  and  image  both  inside  and  outside  the 
enterprise  will  increase  steadily  as  reliance  on  sheer  volume  of 
stored  numerical  data  declines  reflecting  its  value  primarily  as 
a  support  resource. 

(2)  Corporate  Consolidation.  Current  "Mergermania" 
will  further  intensify  before  it  wanes,  thus  fueling  the 
emergence  of  a  two-tiered  vendor  environment  where  a 
comparatively  small  number  of  large  corporations  do  most  volume 
business  and  a  flourishing  legion  of  entrepreneurial  firms 
account  for  the  majority  of  product  innovations. 

(3)  Bureaucratic  Barriers.  Traditional  bureaucratic 
barriers  separating  large-organization  departments  and  personnel 
will  weaken  as  firms  move  to  establish  organically  functioning, 
continuously  interactive,  electronically  linked  operations,  with 
a  workforce  seamlessly  united  in  pursuit  of  overall  corporate 
goals. 


(4)  Management  Realignment.  The  distortion  of 
traditional  pyramid  management  structures  will  accelerate  as 
automation  reduces  entry  level  jobs,  broadens  the  decision  making 
capability  and  power  of  middle  management  specialists  and  by 
eliminating  the  ensuing  redundancy,  simplifies  management  at  the 
top  echelon. 
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NAVSUP  INFORMATION  FLOW 
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NAVSUP  INFORMATION  FLOW 


A .  ORGA  NIZA  TIONS  SHO  WN  IN  THE  A  TTA  CHED  FIGURE  ARE  IDENTIFIED 
IN  ONE  OF  THREE  WA  YS: 

'•  (  ^  ORGANIZATIONS  WITHIN  NAVSUP  S  CLAIMANCT 


J  OTHER  ORGANIZATIONS  WITH  WHICH  NAVSUP  ORGANIZATIONS  INTERACT 


HTRRID  ORGANIZATIONS.  SOME  OP  WHICH  ARE  IN  NAVSUP'S  CLAIMANCT. 
I NAVAL  SUPPLY  CENTERS 


B.  CONNECTING  DATA  FLO  IT  LINES  ARE  SHOWN  IN  ONE  OF  TWO  WATS: 


INDICATES  INFORMATION  FLOW  ASSOCIATED  WITH  A  SUPERIOR/SUBORDINATE 
COMMAND  RELATIONSHIP 


I. 


INDICATES  FUNCTIONAL  SUPPORT  RELATIONSHIP 


C.  ANNOTATED  ON  EACH  INFORMATION  FLOW  LINE  IS  AT  LEAST  ONE 
ALPHA  -ALPHA  NOT  A  TION  OF  BROAD  GROUPS  OF  FUNCTIONAL 
INFORM  A  TION  THESE  GROUPS  A  RE: 


AA  APPN  ACCTG/BILLING 
AC  AIR  CLEARANCE 
Al  AD  HOC  INQUIRIES 
AL  ALLOWANCE  INFO 
Cl  CORPORATE  MANAGEMENT.  INCLUDING 
Al  OB 
IG  OP 
IS  OR 
MR  PO 

CM  CASE  MANAGEMENT  (FMS) 

CR  CONTRACT  MANAGEMENT  REVIEW 
FI  FINANCIAL  INVENTORY  ACCTG 
FM  FOREIGN  MILITARY  SALES  TRANSACTIONS 
IG  INSPECTION 
IL  ILS.  INCLUDING  PPR* 

IS  INFOR  SYSTEM  APPROVALS 
ME  MILITARY  CLOTHING  MATTERS 
MR  MANAGEMENT  OVERSIGHT 


NS  NAVT  STOCK  FUND  BUDGETING 
OB  OPERATING  BUDGET  FORMULATION. 

POM.  EIECUTION 
OP  SUPPLY  CORPS  MANAGEMENT 
PM  PETROLEUM  MGMT.  INCLUDING 
FACILITIES.  RQMTS.  QC 
PO  POLICY 

PP  PERSONAL  PROPERTY.  INCLUDING  QC 
PR  PRINTING  REQUEST 
RD  REDISTRIBUTION  ORDERS 
RF  REFERRALS 

RL  RATION  LAV  ADMINISTRATION 
RO  REPAIR  ORDERS 
RT  RESALE  TRANSACTIONS 
SA  OUTFITTING  t  SUPPLY  ASSISTANCE 
ST  SUPPLY  TRANSACTIONS.  INCL  REQNS. 

STATUS.  BILLING 
SD  SYSTEM  DEVELOPMENT 
SP  STANDARD  PRICES 
Tl  TECHNICAL  INFORMATION 
TR  TRANSACTION  REPORTING 
VS  VEAPONS  SYSTEM  CONFIGURATION 


Figure  3 
6-7 
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(5)  Automated  Expertise.  Artificial-intelligence- 
oriented  software  technology  will  cease  to  be  esoteric,  with  the 
strategic  potential  ...  as  well  as  the  limitations...  of  expert 
systems  becoming  clear  to  the  non-scientific  world  and 
implementation  becoming  commonplace  among  non-technical  corporate 
personnel . 


(6)  User  Sophistication.  The  isolation  of  the 
computer  neophyte,  both  within  the  corporation  and  among  the 
consuming  public,  will  end,  as  technical  proficiency  is  either 
dispersed  through  education  and  experience  or  rendered 
unnecessary  by  the  availability  of  increasingly  "friendly" 
product  offerings. 

(7)  Reoriented  Distribution.  The  demand  for  prompt, 
if  not  instantaneous,  service  and  product  delivery  will  heat  up 
within  the  consuming  public,  thus  placing  distribution  on  a  par 
with  product  development  as  a  primary  strategic  consideration. 
This  will  spur  growth  in  vendor-owned,  electronically  supported 
distribution  systems  and  erosion  of  reliance  on  third-party 
distributors . 

(8)  Technology  Redirection.  With  the  maturing  of 
currently  nascent  hardware,  software,  and  communications 
technologies,  the  conceptual  parameters  of  information  technology 
will  finally  have  been  established.  This  will  require  users  to 
direct  their  energies  toward  creative  optimization  of  existing 
equipment  and  concepts  rather  than  delay  action  in  anticipation 
of  additional  revolutionary  breakthroughs. 

(9)  Consumer  Expectations.  The  steady 
demystification  of  high  technology  will  decrease  consumer 
'.ntimidation,  a  significant  consequence  of  which  will  be  a 
correspondingly  steady  escalation  in  the  buying  public’s 
expectations  and  demands  for  excellence  in  both  products  and 
services. 


b.  IS  technology  will  continue  to  evolve  at  an 
accelerating  rate  of  change  through  the  foreseeable  future. 

c.  The  rate  of  technology  change  is  too  rapid  for 
effective  implementation  or  utilization  of  each  technological 
advance  in  large,  complex  information  systems. 

d.  Relational  data  base  technology  will  further  develop 
i  that  current  cost  disadvantages  will  diminish. 

e.  IBM’s  long  range  direction  toward  its  Strategic 
Application  Architecture  will  accelerate  information  system 
integration  and  interoperability  opportunities. 

Trusted  computer  certification  will  continue  to  lag 
well  behind  demands  for  increased  ADP  security. 
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3.  INFORMATION  SYSTEMS  TECHNICAL  STRATEGIES 


a.  NAVSUP's  capstone  Information  System  strategy  is  to 
sake  data  and  information  available  to  these  with  authorization 
and  need  to  support  effective  and  efficient  accomplishment  of 
NAVSUP's  mission  and  business  strategies. 

b.  A  corollary  to  paragraph  3. a,  preceding,  is  that  the 
information  required  to  support  NAVSUP's  business  and  functional 
strategies  is  the  rational  basis  for  NAVSUP's  information  systems 
strategy. 


c.  Implicit  in  the  foregoing  strategies  is  the  need  to 
expand  the  historical  focus  of  information  support  from  a 
supply-transaction,  record-keeping  orientation  to  a  managerial 
and  executive  support  orientation  at  all  levels  to  facilitate 
better  and  more  timely  decision  making. 

d.  NAVSUP  will  confirm  or  modify  the  business  model  and 
information  categories  of  figures  2  and  3  through  modern  Computer 
Aided  Software  Engineering  (CASE)  tools. 

e.  A  highly  disciplined  methodology  will  be  employed  to 
ensure  that  data  and  business  models  are  transportable  and 
efficient. 


f.  Data  and  business  models  will  be  independent  of 
information  system  execution  technology. 

g.  NAVSUP  will  utilize  an  information  system  technical 
plan,  available  to  all  information  system  planners  and 
developers,  that  fosters  convergence  of  individual  information 
systems  into  a  virtual,  single  system. 

h.  NAVSUP  must  remain  in  a  position  to  take  advantage  of 
modern  information  technology  such  as: 

-  Data  and  processing  distribution 

-  The  growing  power  and  efficiency  of  relational  data 
base  technology. 

-  Intelligent  work  stations  (IWS)  in  the  hands:  of  end 
users  throughout  the  supply  system  including  managers  and 
executives. 


-  Intelligent  network  capabilities. 

-  Artificial  intelligence. 

i.  Based  on  the  preceding  paragraph  h,  NAVSUP  will 
operate  a  logical  three-tier  information  processing 
architecture.  These  tiers  are:  Production,  Departmental,  and  End 
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User.  Figure  4  provides  examples  of  data  and  applications 
resident  in  the  three  tiers. 

j.  NAVSUP  will  pursue  a  policy  of  technology  refreshment 
to  maintain  installed  information  systems  at  or  near  the 
state-of-the-art  for  the  applicable  technologies. 

k.  Hew  technologies  will  be  acquired  as  required  to 
exploit  business  process  opportunities  and/or  reduce  information 
systems  life  cycle  costs. 

l.  New/enhanced  technologies  will  be  selected/applied 
based  upon  a  decision  matrix  which  considers  cost  amortization 
period,  improved  business  process,  impact  of  implementation, 
technology  life,  compliance  with  architectures,  and  compatibility 
with  co-resident  technologies. 

m.  Based  on  information  engineering  principles,  there 
may  be  rational  segmentation  of  data  among  production  values 
(latest  values) ,  archive,  and  management  information. 

n.  Expert  systems  will  be  used  to  document  decision 
rules  and  facilitate  further  automation. 

o.  Functional  requirements  will  drive  technical 
solutions  within  the  constraints  of  the  systems  architecture. 

p.  In  recognition  of  the  trauma  associated  with  change, 
the  introduction  of  change  in  technology  and  information  systems 
should  be  planned  to  minimize  negative  impact  on  the  efficiency 
and  effectiveness  of  the  business  process. 

q.  Production  applications  and  their  supporting  data 
will  be  centrally  managed  and  developed.  Management  and 
information  product  applications  may  be  developed  locally  but 
catalogued  centrally. 

r.  NAVSUP  will  look  first  to  functional  owners  for  data 
processing  functionality.  Unique  systems  will  be  developed  only 
where  significant  data  incompatibility  or  negative  impact  on 
business  exists. 

s.  There  will  be  independent  processes  to  support 
applications,  data  base  access,  and  data  base  management  to 
maximize  portability  and  minimize  costs  of  development  and 
maintenance. 


t.  Data  systems  use  and  development  will  take  place  at 
the  appropriate  level  of  management  hierarchy  commensurate  with 
function  responsibility. 

u.  Annually,  NAVSUP  will  review  and  assess  information 
processing  technology  enhancements  and  opportunities  to  ascertain 
their  efficacy  for  improving  the  cost  effectiveness  of  NAVSUP 
information  processing  and  business  functions. 
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EXAMPLES  OF  DATA  AND  APPLICATIONS 
RESIDENT  IN  THREE-TIER  ARCHITECTURE 


TYPE  OF 
TIER  DATA 


TYPE  OF 
APPLICATIONS 


AUTHORITY 

RESPONSIBILITY 


1. 


CORPORATE 

WIDELY  SHARED 

RAW  DATA 

DATA  DERIVED 

FOR  PRODUCTION 
HISTORICAL  DATA 

DATA  ESTBLSH 

DATA  CHANGE 
CENTRALLY  MGD 
CENTRALLY  MNTD 
PROCESS  CARRIED  TO 
LOGICAL  CONCLUSION 

SUP 

FUNCTIONAL 

OWNER 

CORPORATE  DOWNLOAD 
AUGMENTED  WITH 
ADDITIONAL/DERIVED 
DATA. 

DATA  USE/ 
MANIPULATION 
TRANSACTION 
PREPARATION 

AD  HOC  QUERY 
REPRESENTS 

PROCESS  CTRLS 
DOCUMENT  STORAGE 
DISTRIBUTION 

MANAGEMENT 

AT  THIS  LEVEL 

SPECIALIZED  DWNLD 
DERIVED  DATA 

PERSONAL  DATA 

DECISION  SUPPORT 
SYSTEMS 

TRANS  PREP 
DOCUMENTATION  PREP 

INDIVIDUAL 

Figure  4 
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v.  Technology  assessment  will  be  synchronized  with  the 
POM  process  such  that  the  funding  for  selected  technology 
opportunities  will  be  put  in  place  in  a  timely  fashion. 

w.  NAVSUP  information  systems  will  exploit  automation 
for  managing  systems  and  business  processes. 

x.  Communications  network  capacity  should  be  sufficient 
to  support  the  full  range  of  required  transmission  capabilities, 
including  multi-station  Video  Teleconferencing;  real-time,  3D, 
technical  documents;  batch  file  transfers;  and  interactive 
processing  among  supply  support  nodes.  Additionally,  sufficient 
incremental  capacity  should  be  available  to  support  the  latter 
two  functions  for  the  entire  logistics  community  and  for  internal 
NAVSUP  3D  technical  document  transmissions. 

y.  Strategic  architectures  and  guidelines  for  data, 
applications,  networks,  and  support  systems  will  provide  the 
framework  for  all  information  system  acquisition  and  development 
to  promote  convergence  of  individual  systems  into  a  virtual, 
single  system. 

B.  INFORMATION  PROCESSING  ARCHITECTURE 

This  paragraph  fleshes-out  the  four  architectures  of  the  third 
level  in  figure  1.  Implementation  guidelines  accompany  each 
architecture. 

1.  DATA  ARCHITECTURE 

a.  Figure  5  models  NAVSUP* s  Data  Architecture  for 
managing  data  as  a  corporate  resource.  The  following  paragraphs 
amplify  the  figure  and  describe  the  concepts  of  data  management 
within  NAVSUP  Information  Systems: 

b.  Beginning  at  the  lower  left  of  figure  5,  the  first 
step  in  data  management  is  to  model  the  data  and  their 
inter-relationships.  This  model  is  independent  of  organizations 
and  business  processes  that  use  the  data;  focusing  solely  on  the 
data.  The  model  encompasses  all  NAVSUP  so  that  data  for  all 
business  entities  are  subsets  of  the  logical  corporate  data 
model . 


(1)  The  logical  data  model  is  the  primary  basis  of 
the  data  dictionary  located  in  the  lower  center  of  figure  5.  The 
data  dictionary  contains,  or  points  to,  data  describing  each 
business  data  entity. 

(2)  Behind  the  data  dictionary  lies  the  business 
model.  The  data  dictionary  contains  additional  data  relating 
DENs  to  specific  business  model  functions  and  processes. 
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(3)  The  data  dictionary  also  forms  the  basis  for 
controlling  which  processes  (or  individuals) ,  and  applications 
have  access  to  and  management  responsibilities  for  data  in  the 
physical  data  base  located  in  the  upper  left  portion  of  figure  5. 

(4)  The  physical  data  base  is  a  three-tier 
arrangement  corresponding  to  the  logical  three-tier  architecture: 
production,  departmental,  and  end  user.  Data  dictionary 
discipline  applies  to  all  tiers.  Network  data  bases  should  only 
be  employed  in  currently  operating  information  systems.  All  new 
development  will  employ  relational  technology  as  first  choice. 
Exceptions  to  this  policy  must  be  approved  by  the  System 
Architect.  Over  time,  relational  data  base  technology  will 
replace  network  data  base  technology.  Individual  elements  of  the 
data  base  may  be  geographically  dispersed. 

(5)  An  application  supporting  a  specific  business 
process  appears  in  the  upper  right  portion  of  the  model.  Data  is 
extracted  from  the  virtual,  single  data  base  based  on  the  control 
parameters  of  the  dictionary  and  then  used  in  the  business 
application  directly  supporting  the  business  process. 

c.  With  the  three-tier  strategy,  data  transmissions 
between  tier  data  bases  and  deriving  data  from  higher  level  tiers 
must  be  carefully  managed.  Figure  6  provides  the  Data 
Transmission  Architecture. 

(1)  Central  to  this  architecture  is  a  Data 
Distribution  Manager  that  physically  directs  data  updates  from 
one  tier  to  another. 

(2)  Production,  Departmental  and  End  User  Data 
Dictionaries  are  subsets  of  the  Corporate  Data  Dictionary. 
Corporate  Data  Dictionary  discipline  applies  to  all  tiers  and 
facilitates  access  control  to  data  by  the  Data  Distribution 
Manager. 


(3)  Data  transmission  applications  enhance  data  from 
one  tier  to  another;  for  example,  when  data  from  the  production 
tier  may  be  combined  into  summary  data  for  use  at  the 
Departmental  or  End  User  tier. 

2.  DATA  MANAGEMENT  GUIDELINES 

a.  The  principles  of  Information  Engineering  will  be 
used  to  model  data  for  corporate  data  bases.  The  principles 
reguire  that  data  must  be  analyzed  in  sufficient  detail  to 
eliminate  ambiguous  data  associations  and  redundant  data 
entities.  This  normalized  data  may  then  be  used  in  conjunction 
with  similarly  detailed  analyses  of  the  business  processes  to 
organize  the  business  in  the  most  effective  manner. 

b.  A  single,  corporate,  logical,  data  model  will  be 
developed.  Figure  7  summarizes  the  results  of  using  CASE 
technology  at  the  strategic  data  modeling  level  which  may  cause 
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Figure  B-3 .  Data  Transmission  Architecture 


CORPORATE  DATA  MODEL  (STRATEGIC  LEVEL) 
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figures  2  and  3  to  be  modified  in  ensuing  CIMPs. 

c.  Corporate  data  administration  will  be  supported  by  an 
encompassing  metadata  base  which  supports  development  access, 
redundancy  management,  data  ownership  and  value  validation. 

d.  Logical  data  modeling  is  independent  of  physical 
implementation  and  will  not  be  compromised  to  facilitate  use  of  a 
specific  software  product. 

e.  Data  redundancy  across  the  tiers  may  be  necessary. 

The  production  data  base  will  be  the  source  of  authoritative  data 
values. 


f.  Multiple  data  base  technologies  are  desirable  both 
across  the  processing  tiers  in  order  to  support  performance  and 
within  tiers  to  support  functionality.  The  System  Architect  will 
designate  and  license  specific  DBMS's  to  provide  this 
flexibility.  The  technical  review  process  will  maintain  the  DBMS 
opportunities  current. 

g.  Production  data  segmentation  strategy  will  be  based 
on  information  engineering  principles  to  decide  issues  such  as 
the  separation  of  current  values  from  past  values  to  support 
transaction  performance  and  audit/ analysis. 

h.  Departmental  and  end  user  data  bases  will  be 
supported  by  periodic  snapshots  of  higher-tier  data  bases 
augmented  by  tier  unique  data. 

i.  Data  Access  control  will  be  supported  by  establishing 
and  maintaining  specific  sub-sets  of  the  corporate  Metadata  base 
as  access  controllers  on  top  of  the  data  repositories. 

j .  Tiers  2  and  3  and  external  sources  will  create 
transactions  which  update  the  authoritative,  corporate  data  in 
tier  1.  Updates  will  occur  at  the  tier  that  owns  the  data,  but 
tier  hierarchy  relationships  will  be  maintained. 

k.  Data  interchange  between  and  among  nodes  will  use 
electronic  data  interchange  (EDI)  constructs. 

l.  Data  are  defined  as  facts  or  propositions  used  to 
draw  a  conclusion  or  make  a  decision.  They  are  the  inputs  of  an 
information  system  and  may  take  a  number  of  different  forms  such 
as  image,  various  values,  text,  graphics  or  voice. 

m.  Data  group  archiving  strategy  will  be  effected  in  the 
metadata  base.  The  strategy  will  consider  both  accessible 
storage  options/economics  and  possibilities  of  use/need.  For 
example,  platform  depot  overhaul  intervals  approaching  15  years 
suggest  demand  cycles  15  years  long  for  appropriate  records. 
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3.  APPLICATION  ARCHITECTURE 

a.  Figure  8  portrays  NAVSUP's  Application  Architecture. 

(1)  The  principal  control  agents  in  this 
architecture  are  tier-specific  data  dictionaries  and  user 
profiles  which  control  access  to  data  by  applications  and 
designate  data  management  responsibilities. 

(2)  Tier-specific  data  dictionaries  are  subsets  of 
the  Corporate  Data  Dictionary. 

(3)  Derived  data  applications  are  part  of  the  data 
distribution  management  function  discussed  in  the  Data 
Architecture,  figure  6. 

4.  APPLICATION  GUIDELINES 

a.  Functional  support  ADP  system  development  will 
recognize  the  distinction/segmentation  between  process, data 
entry/exit  and  data  management.  All  should  be  developed  as 
independent  but  related  processes. 

b.  Designated  Computer  Assisted  Software  Engineering 
(CASE)  technology  will  be  used  for  system  design,  development  and 
maintenance  for  centrally  managed  applications. 

c.  User  involvement  will  be  maintained  through  active 
prototype  methodologies  inherent  in  CASE  and  through  total  system 
life  cycle.  Prototype  acceptance  will  constitute 
test/evaluation/ op-review.  The  user  for  any  process  under 
development  is  the  worker,  the  user  of  the  process  product,  and 
management.  The  functional  manager  will  adjudicate  if 
contentions  arise.  Part  of  the  prototype  process  will  be  to 
determine  and  assess  risk  to  supply  and  Navy  resources  that  may 
result  from  the  process. 

d.  Unit  of  program  will  be  the  lowest  level  within  CASE 
development  technology  which  has  an  input  and  an  output.  Input 
can  be  from  a  data  base  or  from  another  program  within  the  same 
application  or  from  an  external  source.  Output  can  be  to  a  data 
base  or  another  program  within  the  application  or  a  view. 

e.  Programs  which  establish  or  change  data  in  the 
corporate  data  base  will  always  be  centrally  managed  and 
maintained. 

f.  The  System  Architect  will  define  the  universe  of 
tools,  either  centrally  developed  or  off-the-shelf,  to  be 
supported  (word  processors,  spread  sheets,  expert  system  shells, 
etc. )  . 

g.  Programs  which  execute  designated  policy  will  be 
centrally  developed,  managed  and  maintained. 
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h.  Programs  which  generate  management 
information/marginal  analysis/"what  if"  analysis  can  be  developed 
locally. 


i.  Programs  which  generate  information  products 
(procurement  instruments,  technical  packages,  etc.)  may  be 
developed  locally.  It  is  understood  that  the  product  content 
will  remain  constant;  format  and  media  may  vary. 

j.  With  the  CASE  development  process,  logic  and  action 
diagrams  will  be  developed  independently  of  a  target  language  or 
processing  environment. 

k.  A  repetitive-use  central  software  configuration 
catalog  containing  both  centrally  managed  and  locally  developed 
programs  will  be  maintained  by  the  Central  Design  Activity 
(FMSO) . 

l.  All  updates  and  changes  to  corporate  data  will  be 
ledgered.  (Note;  This  is  to  be  a  data  service. .. .not  an 
application  function.) 

m.  As  stated  in  paragraph  A.3.s,  above,  there  will  be 
independent  processes  to  support  applications,  data  base  access, 
and  data  base  management  to  maximize  portability  and  minimize 
cost  of  development  and  maintenance. 

n.  Applications  will  be  developed  using  languages  that 
provide  the  least  total  life  cycle  cost  of  the  system  and  the 
supported  business  processes. 

5 .  NETWORK  ARCHITECTURE 

a.  navsup  telecommunications  facilities  will  be 
integrated  into  a  single  logical  network  as  indicated  in  figure 
9.  This  network  is  called  the  NAVSUP  Logistic  Network  (NLN) . 

b.  Physically  distinct  subnets,  based  on  security 
classification,  community  of  interest,  regional  or  campus 
orientation,  or  host  processing  suite  will  co-exist  with  and 
complement  the  NLN,  unless  specifically  exempted. 

c.  In  general,  the  standard  NAVSUP  internal  architecture 
is  a  Systems  Network  Architecture  (SNA)  implementation,  focusing 
inward  to  the  ICP  or  SPAR  central  processing  hosts.  Non-IBM 
compatible  processing  devices  wishing  access  to  the  internal 
network  must  support  SNA  compatibility  in  communications  hardware 
and  software,  in  addition  to  any  native  mode  telecommunications 
capabilities  provided  within  a  regional  area. 
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NAVSUP  LOGISTIC  NETWORK  (NLN) 
ARCHITECTURE 


Figure  9 


6.  NETWORK  GUIDELINES 


a.  SPLICE  will  provide  most  of  the  long-haul 
communications  capabilities  of  the  NLN  nodes  during  its  economic 
life.  Its  replacement  will  be  hardware  and  software  acquired  via 
technological  refreshments  from  the  ICP  and  SPAR  contracts. 

b.  Telecommunications  capacity  will  be  provided  in  two 
operational  areas: 

(1)  Interoperable  Communications  - 

(a)  Government  Open  Systems  Interconnection 
Profile  (GOSIP)  will  be  the  standard  method  for  interoperable 
long  haul  data  communications.  Until  the  implementation  of 
GOSIP,  the  Defense  Data  Network  (DDN)  with  the  DOD  mandated  lower 
level  protocols  will  be  used.  Gateways  will  be  provided  which 
utilize  the  upper  level  DOD  protocols.  Nodes  will  have  at  least 
two  DDN  host  connections  terminating  at  different  Packet 
Switching  Nodes  (PSNs) . 

(b)  All  NAVSUP  activities  will  install  a 
backbone  IEEE  802.5  compatible  Local  Area  Network  (LAN)  in  the 
near  future.  These  installations  will  be  done  with  the  approval 
of  the  local  coordinator  of  the  Base  Information  Transfer  System 
(BITS)  project.  Other  sites  using  NAVSUP  Automated  Information 
Systems  (AISs)  will  implement  a  LAN  in  accordance  with  the  BITS 
project.  In  either  case,  most  workstations/terminals  will  be 
attached  to  this  LAN.  At  NAVSUP  activities,  bridges  to  other  IEEE 
802  series  standard  LANs  will  be  used,  if  required  for  projects 
such  as  EDMICS. 

(c)  Voice  communications  will  be  used  as 
provided  via  the  BITS  or  Bases  and  Stations  Information  System 
(BASIS)  projects. 

(2)  Closed  community  - 

(a)  Selected  DDN  connection  will  be  used  for 
closed  community  operations  (i.e.,  NLN  host-to-NLN  host  only). 
Optimized  vendor  unique  X.25  and  upper  level  protocols  will  be 
used. 

(b)  Government  provided  and  contractor  provided 
leased  lines  will  be  used  to  supplement  DDN,  where  required. 

(c)  The  NAVSUP  Video  Teleconferencing  project 
will  be  implemented  at  all  NAVSUP  Stock  Points,  as  well  as  HQ  and 
the  I CPs.  This  project  will  allow  shared  use  of  their  large 
communications  "pipes"  for  data  traffic,  as  well  as  video. 

c.  The  NLN  community  will  standardize  on  Personal 
Computers  (PCs)  as  intelligent  workstations.  These  devices  will 
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be  capable  of  supporting  several  vendor  unique  protocols  through 
the  use  of  hardware  boards  and  software  communications  packages. 
"Dumb"  terminal  devices  will  be  phased-out  on  a  priority  basis. 

d.  The  NLN  community  will  standardize  on  PC  attached, 
slow  speed  printers  and  front-end  processor  (FEP)  attached 
high/medium  speed  and  laser  printers  for  non-computer  room  print 
requirements. 

e.  Card  reader/punch  equipment  will  not  be  supported 
anywhere  on  the  network  nor  in  any  FMSO  designed  modernization 
applications.  Card  reader/punch  equipment  used  in  support  of 
external  customers  will  be  phased  out  at  the  earliest  possible 
date . 


f.  "Lights  out"  data  center  operations  and  personnel 
reductions  will  force  remote  data  communications  management  and 
problem  diagnosis  to  be  centralized  at  the  NAVSUP  Network  Control 
Center.  Local  sites  will  use  any  remaining  telecommunications 
resources  as  LAN  support  personnel. 

g.  Host  channel  connections  vice  LAN  gateways  will 
interconnect  the  heterogeneous  host  equipment  at  a  node,  if 
interconnection  is  required. 

h.  On-line  file  transfers  will  be  accomplished  among 
regionally  co-located  heterogeneous  hosts  via  IBM  protocols. 
Homogeneous  hosts  may  use  more  optimized  off-the-shelf  host 
transfer  methods.  PC-to-host  file  transfers  will  be  supported 
via  native  mode  host/PC  off-the-shelf  software  packages. 

i.  The  IBM  NETVIEW  product  will  be  the  strategic  network 
management  and  control  product  implemented  at  all  levels  of  the 
network,  including  the  TANDEM  nodes. 

j.  Network  control  equipment,  modems,  and  LAN  equipment 
will  be  purchased  from  the  SPAR  and  ICP  Resolicitation  contracts 
containing  those  required  equipment  items. 

k.  Only  full  screen,  block  mode  applications  written  in 
accordance  with  the  above  will  be  used  on  the  network. 

7.  SUFPORT  SYSTEM  ARCHITECTURE 

a.  The  Support  System  Architecture  shown  in  figure  10  is 
intended  to  assure  interoperability  across  all  tiers  and  to 
promote  re-use  of  application  software  throughout  the  supply 
system. 


b.  The  Corporate  Data  Dictionary  in  conjunction  with  the 
Business  Model  will  control  applications  as  they  relate  to 
business  processes. 
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SUPPORT  SYSTEM  ARCHITECTURE 


c.  The  Configuration  and  Capacity  Data  Base  will  contain 
hardware  inventory  information  and  capacity  metrics  as  well  as 
operating  system  software  and  business  application  software 
inventory  information  and  metrics. 

d.  The  Configuration  and  Capacity  Manager  is  a  decision 
support  system  providing  standard  reports  as  well  as  ad  hoc 
analytical  capabilities. 

8.  SUPPORT  SYSTEM  GUIDELINES 

a.  The  Support  System  Configuration  Accounting  and 
Management  System  will  be  the  same  methodology  as  that  used  by 
Navy  for  Weapon  System  configuration  management  (SCLSIS) . 

b.  System  hardware  and  software  will  support  the 
multi-tiered  data  architecture. 

c.  NAVSUP  activity  system  configuration  will  be 
compatible  to  allow  mutual  processing/support  between  sites.  The 
System  Architect  will  develop  and  maintain  a  menu  of  system 
support  software  to  facilitate  this  compatibility. 

d.  Each  NAVSUP  business  function  will  be  supported  by  a 
consistent  set  of  hardware  and  system  software  in  order  to  assure 
commonality  of  processing  across  sites. 

e.  System  will  support  Electronic  Data  Interchange 
protocol  interaction  between  sites  and  customer/user  systems. 

f.  Commercially  developed  and  maintained  hardware  and 
software  will  be  utilized  by  all  NAVSUP  sites  and  systems. 

g.  System  hardware  and  software  will  support  automated 
operations . 


h.  Capacity  planning  and  management  will  take  place 
centrally. 

i.  System  performance  and  capacity  standards  will  be 
developed  and  maintained  by  the  System  Architect. 

9.  Summary:  The  overall  technical  view  embodied  in  this 
plan  is  pictured  in  figure  11.  Implementing  the  concepts  behind 
the  strategies  and  guidelines  discussed  in  this  section  of  the 
plan  will  require  support  of  end  users,  data  processing  and 
telecommunications  professionals  throughout  NAVSUP  and  other  Navy 
supply  activities.  Realistically,  full  implementation  of  these 
architectures  will  not  be  achieved  before  the  mid-1990's.  In  the 
short  term,  NAVSUP  will  review  its  information  system  development 
policies  and  revise  or  issue  policies  to  enable  achieving  figure 
11. 
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APPENDIX  C 


NAVSUP  DATA  ADMINISTRATOR  SURVEY 


1.  Does  the  Data  Administrator  perform  data  administration 
functions  full-time  or  part-time? 

2.  If  part-time,  approximately  what  percentage  of  time  is 
spent  on  data  administration? 

3 .  How  many  people  that  perform  data  administration 
functions  work  directly  for  the  DA? 

4 .  What  is  the  title  and  code  of  the  person  the  DA  reports 
to? 

5.  Is  a  Data  Base  Administrator  assigned  (yes/no)?  If  yes, 
full-time  or  part-time? 

6.  What  is  the  title  and  code  of  the  person  the  DBA  reports 
to? 

7.  Check  the  following  functions  and  responsibilities  the 
DA  has  performed: 

a.  Implement  policies  and  standards  on 
activity/corporate  databases. 

b.  Maintain  logical  and  physical  integrity  of 
activity/corporate  databases. 

c.  Evaluate  and  approve  proposals  for  local  unique 
databases  and  use  of  activity/corporate  databases. 

d.  Ensure  logical  and  physical  database  design  of 
activity  databases  comply  with  NAVSUP  policies. 

e.  Monitor  activity  databases  to  ensure  adherence  to 
approved  standards. 

f.  Prepare  and  maintain  database  resource  plan. 

g.  Identify  and  resolve  inconsistencies  within 
corporate  data  structure. 

h.  Draft,  for  Headquarters  DA  establishment,  MOA/SLAs 
with  appropriate  CDAs  as  required. 


118 


i.  Develop  and  execute  operational  and  management 
training  on  data  management. 

j .  Provide  recommendations  to  the  NAVSUP  DA  on  changes 
in  database  management  policy  and  procedures. 

k.  evaluate  proposals  from  field  activities  and 
external  CDAs  relating  to  changes  in  policy  and 
structure  associated  with  data  management,  and  made 
appropriate  recommendations. 

l.  Identify  data  sharing  opportunities. 

m.  Develop  tactical/strategic  plans  for  data  use. 

n.  Identify  potential  database  applications. 

Does  the  DA  use  a  Data  Dictionary  or  Dictionaries  in 
carrying  out  assigned  functions  and  responsibilities? 
(yes/no) 

a.  If  yes,  is  the  primary  DD  active  or  passive? 

b.  Approximately  how  many  entries  are  in  the  primary 
DD? 

c.  Who  makes  inputs  to  the  DD?  (DA,  DBA,  Systems, 
Applications,  or  other) 

d.  Check  the  primary  uses  of  the  DD: 

1.  As  a  tool  for  Systems  Planning. 

2.  As  a  tool  for  Requirements  Definition  and 
Analysis. 

3.  As  a  tool  for  Design,  Implementation,  Testing, 
Operation  and  Maintenance. 

4.  As  a  tool  for  Documentation  and  Standards. 

5.  As  a  tool  for  Operational  Control  Through 
Metadata  Generation  and  Metadata  Audit  Trail. 

6.  As  a  tool  to  Support  the  Distributed  Database 
Environment. 


7.  List  other  uses: 


9.  Does  the  DA  feel  that  the  data  administration  concept, 
as  it  is  organized  at  her/his  activity,  has  been 
successful? 

yes  no 

partially  don't  know  or  too  early  to  tell 

10.  Check  the  Data  Administration  and  Management  problems 
that  exist  within  your  activity: 

a.  Lack  of  qualified  DA  staff. 

b.  Inadequate  grade  levels  (salaries) . 

c.  Not  enough  responsibility. 

d.  Too  heavy  a  workload. 

e.  Responsibility  without  corresponding  authority. 

f.  Resistance  by  others  to  changing  job 
responsibilities . 

g.  lack  of  enough  management  support. 

h.  DA  group  not  placed  high  enough  in  the  organization. 

i.  Resistance  to  data  sharing  by  users. 

j.  Resistance  to  data  sharing  by  systems  people. 

k.  Management  lack  of  understanding  of  the  Data 
Administration  concept. 

l.  List  other  problems: 
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11.  Check  any  benefits,  perceived  or  real,  that  your 
activity  has  realized  from  the  use  of  a  data  dictionary 

a.  Elimination  of  redundant  metadata  definition. 

b.  Insured  consistency  in  the  metadata. 

c.  Establishment  of  control  over  metadata  usage. 

d.  Establishment  of  control  of  metadata  changes. 

e.  Implementation  of  data  independence. 

f .  Reduced  coding  (active  DD) . 

g.  Consistency  of  documentation. 

h.  List  other  benefits  realized: 

12.  If  you  have  time,  please  comment  on  major  data 
administration  and  management  directions  you  plan  to 
take  in  the  future. 


121 


LIST  OF  REFERENCES 


1.  NAVSUP  Inventory  and  Information  Systems  Development 
Strategic  Plan,  FY89,  SUP  04. 

/ 

2.  D'Cunha,  Adolph  and  Radhakrishnan,  T.,  " DAAS : A  Data 
Administration  Support  System,*1  The  Journal  of  Systems 
and  Software.  Vol.  4,  July  1984. 

3.  Caudle,  Sharon  L. ,  "Off  the  IRM  Mark  at  the  Federal 
Level,"  Journal  of  Systems  Management.  August  1988. 

4.  U.S.  Department  of  Commerce,  National  Bureau  of 
Standards ,  NBS  Special  Publication  500-512.  Guide  to 
Information  Resource  Dictionary  System  Applications: 

General  Concepts  and  Strategic  Systems  Planning. 

Government  Printing  Office,  Washington,  DC.  1988. 

5.  Kahn,  Beverly  K. ,  "Some  Realities  of  Data 
Administration,"  Communications  of  the  ACM.  Vol.  26, 

No  10,  October  1983. 

6.  Wertz,  Charles  J.,  The  Data  Dictionary:  Concepts 
and  Uses.  QED  Information  Sciences,  Inc.,  1986. 

7.  Telephone  conversation  between  Dr.  Alan  Goldfine, 

Institute  for  Computer  Sciences  and  Technology, 

National  Bureau  of  Standards,  and  the  authors,  19 
October  1988. 

8.  Narayan,  Rom,  Data  Dictionary:  Implementation.  Use 
and  Maintenance.  Prentice-Hall,  1988. 

9.  Gillenson,  Mark  L. ,  "The  State  of  Practice  of  Data 
Administration  -  1981,"  Communications  of  the  ACM. 

Vol.  25,  No  10,  October  1982. 

10.  American  Management  Systems,  Inc.,  Final  Data 
Administration  Policy  Evaluation  Report  to  the  Naval 
Supply  Systems  Command  (NAVSUP^  for  the  Development  of 
a  Corporate  Data  Dictionary  Concept.  General  Services 
Administration,  National  Capital  Region,  Contract 
GS-OOK-85-AFD2777,  26  January  1988. 

11.  Dolk,  Daniel  R.  and  Kirsch,  Robert  A.  II,  "A 
Relational  Information  Resource  Dictionary  System," 

Communications  of  the  ACM.  Vol.  30,  No  1,  January  1987.  * 


122 


1 


12.  Whitten,  J.  L. ,  Bentley,  L.  D. ,  Ho,  T.  I.  M. ,  System 
Analysis  &  Design  Methods.  Times  Mirror/Mosby  College 
Publishing,  1986. 

13.  Leong-Hong,  Belkis  W. ,  and  Plagman,  Bernard  K. ,  Data 
Dictionary/Directorv  Systems:  Administration. 
Implementation  and  Usage.  John  Wiley  &  Sons,  Inc., 
1982. 

14.  Knight,  R. ,  Data  Administration  and  Its  Role  at  Naval 
Supply  Systems  Headquarters.  Master's  Thesis,  Naval 
Postgraduate  School,  Monterey,  California,  September 
1985. 

15.  Stanley,  S.  A.,  Information  Engineering  in  the 
Department  of  Defense:  Two  Case  Studies ,  Master 1 s 
Thesis,  Naval  Postgraduate  School,  Monterey, 
California,  September  1988. 

16.  NAVSUP  Data  Administrator,  NAVSUP  Instruction  5231.1, 
SUP  0414,  12  June  1986. 

17.  NAVSUP  Data  Administrator,  NAVSUP  Instruction  5231.2, 
SUP  0414,  27  February  1987. 

18.  American  Management  Systems,  Inc.,  Final  NAVSUP 
Corporate  Data  Dictionary  Development  and 
Implementation  Altnatives.  General  Services 
Administration,  National  Capital  Region,  Contract 
GS-OOK-85-AFD2777,  30  March  1988. 

19.  Fleet  Material  Support  Office,  Draft  Requirements 
Statement  for  Modernization  Data  Dictionary  Expansion. 
FMSO  Code  9203,  April  1988. 

20.  American  Management  Systems,  Inc.,  Final  Data 
Administration  Policy  Evaluation  Report  to  the  Naval 
Supply  Systems  Command  (NAVSUP)  for  the  Development  of 
a  Corporate  Data  Dictionary  Concept.  General  Services 
Administration,  National  Capital  Region,  Contract 

GS -00K-8 5 -AFD2 777,  26  January  1988. 

21.  Stoner,  James  A.  F.  and  Wankel,  Charles,  Management, 
Prentice-Hall,  1986. 


123 


INITIAL  DISTRIBUTION  LIST 


No. 

1.  Defense  Technical  Information  System 
Cameron  Station 

Alexandria,  Virginia  22304-6145 

2.  Library,  Code  0142 
Naval  Postgraduate  School 
Monterey,  California  93943-5002 

3.  Computer  Technology  Curricular  Office,  Code  37 
Naval  Postgraduate  School 

Monterey,  California  93943-5000 

4.  Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Professor  Daniel  R.  Dolk,  Code  54Dk 
Monterey,  California  93943-5000 

5.  Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Professor  E.  Neil  Hart,  Code  54Hr 
Monterey,  California  93943-5000 

6.  Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Professor  Robert  Knight,  Code  54Kt 
Monterey,  California  93943-5000 

7.  Commander  Naval  Supply  Systems  Command 
Code  SUP- 04 

Washington  D.C.  20376 

8 .  Commander  Naval  Supply  Systems  Command 
Code  SUP-0414 

Washington  D.C.  20376 

9.  Commanding  Officer 

Navy  Accounting  and  Finance  Center 
Attn:  Director  IRM  Division 

Room  416 

Washington  D.C.  20376 


Copies 

2 


2 


1 


1 


1 


1 


1 


1 


1 


124 


10.  Commanding  Officer 
USS  PROTEUS  (AS  19) 

Attn:  LCDR  Mark  H.  Barber,  SC,  USN 

Assistant  Supply  Officer 
FPO  San  Francisco,  CA  96646-2575 

11.  Commanding  Officer 

Fleet  Material  Support  Office 
Attn:  LCDR  Paul  Richey 

5450  Carlisle  Pike 
Mechanicsburg,  PA  17055-0787 


125 


